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Preface 


The  following  document  is- the-result  of  a  semester  long  independent  study  course  at  Johns 
Hopkins  University  (JHU).  Tfiis  document  discusses  the  concept  development  stage  of  a 
conceivable  system  to  monitor  data  from  a  Fibre  Channel  avionics  bus  for  test  purposes. 
Specifically  it  addresses  the  system  need  (why)  and  the  system  requirements  (what).  The 
document  also  contains  several  top-level  discussions  as  to  implementation  options  (how). 

This  document  was  a  tool  used  by  JHU  to  assess  my  ability  to  apply  skills  and  processes  learned 
throughout  the  JHU  Systems  Engineering  curriculum.  It  is  important  to  keep  in  mind  this 
document  was  written  by  me  to  satisfy  JHU  requirements  and  does  not  necessarily  reflect  the 
views  of  the  Naval  Air  Warfare  Center.  This  was  a  semester  long  project  and  many  of  the 
ideas  and  concepts  will  need  to  be  further  developed  and  refined  to  be  useful  to  a  funded 
development  effort. 

Now  that  the  class  is  complete,  it  is  my  sincere  hope  that  the  Telemetry  Community  will  find  this 
document  useful  in  pursuing  the  development  of  a  Fibre  Channel  Avionics  Bus  Monitor  System. 


1  statement  of  Objective  and  Approach 

There  were  two  major  objectives  to  this  project.  The  first  was  to  apply  the  knowledge  gained 
through  the  Johns  Hopkins  System  Engineering  curriculum  to  a  real  world  problem.  The  second 
was  to  use  the  processes,  skills,  and  concepts  learned  on  the  selected  project  to  lay  the  groimd 
work  for  a  development  program. 

Test  and  Evaluation  (T&E)  data  systems  acquire  data  from  a  test  or  mission  fi'om  a  variety  of 
sources  depending  on  the  type  of  test  being  performed.  These  sources  include  avionics 
computers,  avionics  busses,  aircraft  subsystems,  and  a  host  of  specific  transducers.  The  vast 
majority  of  installations  require  monitoring  the  data  being  sent  between  the  avionics  computers 
over  the  avionics  bus.  For  the  past  twenty  years,  the  avionics  bus  used  in  most  aircraft  is  the 
Mil-Std-1553  multiplex  bus.  The  architecture  and  speed  of  the  Mil-Std-1553  bus  made 
monitoring  the  data  relatively  easy.  During  the  last  couple  of  years,  it  was  discovered  that 
several  airframes  were  looking  at  a  new  technology  (i.e.  Fibre  Channel)  for  the  aircraft’s 
avionics  busses.  Fibre  Channel  utilizes  a  high-speed  network  architecture  that  requires  a 
significantly  different  approach  to  monitor  the  data  during  a  flight  test. 

The  objective  of  this  project  was  to  develop  a  systems  requirement  specification  (A-Spec)  for  a 
Fibre  Channel  Avionics  Bus  Monitor.  The  resultant  specification  would  be  used  as  the  basis  for 
a  development  or  research  contract.  In  developing  the  A-Spec,  the  systems  engineering 
approach  was  used  as  a  model  for  defining  and  executing  the  activities  and  tasks  required.  The 
project  was  grouped  into  three  phases  that  provided  an  organized  sequence  of  system 
engineering  activities.  The  first  phase  was  Problem  Definition  in  which  the  needs  and 
operational  concepts  were  identified  and  defined.  The  second  phase  was  Functional  Analysis  in 
which  the  requirements  analysis  and  assessment  was  completed.  The  third  phase  was  Physical 
Analysis  where  trade-off  studies  and  the  final  A-Spec  were  completed. 

2  Significance  of  Scope  of  Work 

The  significance  of  this  project  personally  is  that  it  forced  me  to  think  through  the  project  goals 
from  a  systems  engineering  perspective.  From  a  broader  perspective,  I  think  this  project  will 
motivate  the  community  to  consider  this  problem.  As  budgets  get  tightened  and  work  load 
increases,  many  agencies  focus  on  the  task  at  hand.  They  wonder  where  the  latest  fire  drill  came 
from  and  why  they  didn’t  see  it  coming.  I  believe  this  could  potentially  be  the  case  with 
monitoring  advanced  network  based  avionics  systems.  The  goal  is  to  foster  an  interest  by  using 
the  A-Spec  as  the  basis  for  a  research  or  development  contract.  However,  even  if  there  is  no 
product  produced  as  a  direct  result  of  this  project,  a  product  will  be  produced  in  the  near  future 
that  will  have  roots  going  back  to  the  efforts  of  this  project. 

Lessons  Learned 

•  While  a  lot  of  work,  this  project  provided  the  opportunity  to  follow  the  system  engineering 
approach  through  a  significant  portion  of  a  real  world  project.  We  were  taught  the  traditional 
systems  engineering  waterfall  vsdth  feedback  paths.  During  this  project,  I  was  required  to 
constantly  keep  the  whole  concept  in  mind  while  working  on  particular  pieces.  While 
producing  subsequent  products,  new  thoughts  and  ideas  emerge  that  require  updating 
previous  documents.  Doing  individual  documents  piecemeal  throughout  the  curriculum, 
some  of  this  gets  lost. 
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•  Along  these  lines,  the  concept  of  tailoring  the  documents  hit  home.  While  writing  the 
Systems  Engineering  Master  Plan  (SEMP)  in  a  previous  class,  we  were  told  to  tailor  it 
appropriately.  Once  you’re  immersed  in  a  real  world  project,  the  concept  of  tailoring 
crystallizes.  There  were  some  aspects  to  the  documents  that  didn’t  fit  the  task  at  hand  while 
in  other  cases  there  were  pieces'that  needed  to  be  added. 

•  I  did  a  fair  job  of  estimating  the  work  required  for  the  project,  but  I  did  a  less  than  stellar  job 
of  estimating  the  rate  at  which  the  tasks  would  get  done.  A  good  schedule  must  not  only 
have  the  appropriate  task  levels,  but  must  be  realistic  in  the  time  line  as  well.  I  should  have 
reassessed  my  schedule  more  often  to  keep  better  tabs  on  the  project. 

•  User  feedback  is  an  important  element  of  the  system  engineering  process.  However,  in  these 
days  of  doing  more  with  less,  many  people  barely  have  time  to  do  their  own  jobs  without 
worrying  about  reviewing  documents  for  another  project.  Such  was  the  case  during  this 
project.  ‘User  feedback’  came  in  the  form  of  doing  more  up-ffont  discussions  before  writing 
the  document. 

•  The  use  of  trade  studies  is  very  important  from  a  systems  engineering  approach.  One  thing 
that  is  not  emphasized  enough  is  the  two  reasons  to  do  a  trade  study  have  slightly  different 
requirements.  A  good  trade  study  must  fully  address  both.  The  obvious  reason  is  use  a 
systematic  approach  to  make  a  decision  between  competing  solutions.  However,  in  doing 
that,  it  is  not  enough  to  choose  the  best  candidate.  The  trade  study  should  be  written  from  the 
perspective  that  you  will  need  to  defend  your  choice  at  some  later  time.  This  means  ensuring 
all  assumptions,  alternatives,  etc  are  documented. 

3  Description  of  Products/Results 

3.1  Project  Concept 

■  Identifies  a  JHU  System  Engineering  Project  concept. 

■  Documents  the  project  concept  for  acceptance. 

■  Additional  concept  information  provided  in  response  to  questions. 

3.2  Project  Proposal 

■  Identifies  the  project  objectives. 

■  States  the  need  for  the  proposed  system. 

■  Describes  the  products  to  be  generated. 

■  Identifies  the  system  engineering  scope  of  the  project. 

■  Identifies  the  resources  required  for  the  project. 

■  Identifies  the  preliminary  task  breakdown. 

■  Provides  the  project  milestones  and  master  schedule. 

■  Provides  a  project  risk  assessment. 

3.3  Statement  of  Need 

•  Identifies  why  the  Fibre  Channel  Avionics  Bus  is  needed. 

■  Identifies  the  scope  of  the  project. 

■  Provides  background  information  pertinent  to  the  project. 

■  Describes  deficiencies  in  current  bus  monitor  systems. 

■  Lists  non-materiel  alternatives  considered  adequate. 

■  Lists  potential  materiel  alternatives. 

■  Identifies  constraints  placed  on  the  system. 
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3.4  Operational  Concept  Document 

■  Identifies  the  state  of  the  current  system. 

■  Identifies  justification  for  proposed  changes. 

■  Provides  the  concept  envisioned  for  the  new  or  improved  system. 

■  Describes  how  the  new  system  will  be  utilized. 

•  Identifies  impacts  the  new  system  will  have  on  current  operations. 

3.5  External  Interface  Requirements 

■  Identifies  the  external  interfaces  as  seen  by  a  Fibre  Channel  Avionics  Bus  Momtor. 

■  Describes  each  of  the  external  interfaces  in  detail. 

3.6  System  Requirements 

■  Defines  the  system  operational  requirements. 

■  Describes  the  system  in  relation  to  interfacing  systems. 

■  Describes  a  conceptual  operation  of  the  system. 

3.7  Trade  Studies 

■  Provides  a  systematic  approach  to  select  among  a  group  of  alternatives. 

■  Describes  each  alternative. 

■  Identifies  the  criterion  in  which  the  selection  is  based. 

•  Describes  approach  and  identifies  selection. 

3.8  Interim  Report 

■  Provides  a  detailed  look  at  the  status  of  the  project. 

■  Reaffirms  or  updates  project  objectives,  approach,  and  schedule. 

•  Summarizes  the  progress  achieved  to  date. 

3.9  System  Requirements  Specification 

■  Defines  the  minimum  system  capabilities  required  for  the  system. 

■  Correlates  system  capability  requirements  to  the  required  states  and  modes  of  the  system. 

■  Identifies  design  constraints  for  compatibility  of  system  hardware. 

■  Provides  matrix  to  qualify  system  requirements. 

3.10  Final  Report/Presentation 

■  Provides  the  final  status  of  the  project. 

■  All  project  deliverables  are  combined  into  one  document. 

■  Provides  conclusions  and  recommendations  on  any  additional  effort  required. 

■  Summarizes  project  in  oral  presentation. 

4  Project  Evaluation 

The  project  provided  a  good  opportunity  to  apply  the  skills  and  techniques  learned  throughout 
the  curriculum  to  something  real.  The  project  impressed  two  major  ideas  on  me.  The  first  was 
that  even  though  you  think  you  have  a  good  grasp  on  the  project,  working  systematically  through 
each  activity  forces  you  to  think  along  lines  you  hadn’t  considered  at  first.  The  second  was 
along  with  the  first  idea;  the  iterative  nature  of  a  systems  approach  really  stands  out. 

I  feel  this  work  has  met  both  objectives  stated  up  front.  The  first  was  to  apply  what  was  le^ed 
in  the  program  to  a  real  project.  In  spite  of  the  amount  of  work  this  project  has  been,  I  feel  it^s 
solidified  my  knowledge  and  confidence  in  the  systems  engineering  area  significantly.  1  e 
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second  objective  was  to  develop  a  requirements  specification  for  a  Fibre  Channel  Bus  Monitor 
(which  can  be  found  in  appendix  J).  Regardless  whether  a  development  contract  is  generated  as 
a  result  of  this  project  or  is  provided  to  interested  vendors  as  reference  material,  I  feel  the  project 
has  been  successful.  At  the  very  least,  the  community  (government  and  vendors)  will  be  aware 
of  the  need  for  such  a  capability  and  will  hopefully  act  from  an  informed  position  whether  to 
pursue  a  development  or  not. 

The  overall  estimate  of  the  work  required  to  complete  this  project  was  not  far  from  the  actual 
values.  This  is  mostly  due  in  part  to  the  guidance  concerning  the  scope  given  in  the  project 
handout  than  to  good  estimation  practices  on  my  part.  I  imiformly  had  to  increase  my  estimate 
by  50%.  As  a  result,  that  turned  out  to  be  a  good  data  point  unto  itself.  I  know  that  I  typically 
estimate  work  requirements  low  and  must  compensate.  Table  1  provides  the  comparison  of 
estimated  hours  to  actual  hours. 


Table  1  Project  Summary  (Hours  per  Task) 


vjEstimatediHouM 

m 

1 

I 

Write  Concept 

11 

Eroposal 

15 

18 

Needs  analysis 

15 

17 

Requirements  Analysis 

— 

— 

Concept  of  Operations 

39 

39 

Identify  external  interfaces 

16 

23 

Identify  system  requirements 

10 

16 

Trade  Studies 

— 

— 

Bus  tap  method 

29 

23 

Development  Technology 

25 

27 

Interim  Report 

12 

6 

System  Specification 

29 

23 

Final  Report 

15 

13 

Oral  Report 

7 

12 

5  Conclusions  and  Recommendations 

One  of  the  difficult  aspects  of  this  project  has  been  the  desire  to  develop  a  capability  nearly  in 
parallel  with  the  technology  it  needs  to  monitor.  The  weapons  platforms  that  are  upgrading  their 
avionics  systems  are  still  in  their  infancy.  Many  interface  documents,  data  design  documents, 
and  overall  operational  concepts  are  still  in  work  and  not  released.  This  will  require  much  of  the 
work  performed  on  this  project  to  be  reevaluated,  as  this  information  becomes  available.  Though 
this  may  seem  like  a  negative,  I  think  it  is  better  characterized  as  a  known  risk.  To  wait  until  all 
pertinent  documents  were  officially  signed  out  and  in  use  would  mean  this  work  would  never  get 
done. 

Considering  the  work  that  was  accomplished  on  this  project,  I  don’t  think  I  would  change 
anything  in  particular.  For  the  effort  expended,  there  is  a  lot  of  useful  information  captured. 
However,  given  additional  time  I  would  look  into  the  data  flow  and  format  of  the  various  data 


4 


types  in  more  detail.  Knowing  more  about  the  data  will  potentially  point  to  new  or  more 
stringent  requirements. 

One  of  the  big  concerns  going  into  this  project  was  the  method  of  tapping  into  a  fiber  optic  bus. 
I  have  not  had  much  experience  with  practical  applications  like  an  avionics  system.  Past 
experience  with  copper-based  avionics  busses  has  shown  how  seriously  adding  failure  modes  to 
the  flight  system  is  taken.  With  any  optical  tap,  the  avionics  bus  has  some  non-standard  part  in¬ 
line.  If  that  part  were  to  fail,  that  leg  of  the  bus  goes  dark.  The  combination  of  the  seriousness 
of  the  tap  and  the  newness  of  the  technology  application  will  require  quite  a  bit  of  additional 
research  in  this  area.  Some  conversations  I’ve  had  recently  indicate  the  optical  splitters  may  be 
passive  devices  that  simply  split  the  optical  power  in  half.  I  doubt  the  avionics  are  being 
designed  to  handle  a  50%  reduction  in  optical  power  in  case  an  instmmentation  system  might  be 
used. 
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Appendix  A 


Project  Concept 


System  Engineering  Project  Concept 

Fibre  Channel  Avionics  Bus  Monitor 

Sid  Jones 

Fall  2000 


Project  Objectives 

The  objective  for  this  project  is  to  rigorously  identify  the  most  promising  solution  for  a  Fibre 
Chainel  Avionics  Bus  Monitor.  Upon  completion,  the  final  report  may  be  included  in  a 
procurement  package  or  given  to  vendors  in  order  to  gain  a  commercial  product  to  fill  this  need. 


Need  for  System 

Acquisition  Reform  has  allowed  the  DoD  to  quickly  integrate  state  of  the  art  commercial 
products  into  the  weapons  platforms.  One  such  area  is  the  integration  of  network  technology 
into  the  avionics  suite.  There  is  a  concern  this  is  happening  faster  then  the  Test  and  Evaluation 
community  can  react  with  proper  instrumentation  practices  and  products. 

For  the  past  20  years,  the  avionics  bus  used  on  military  aircraft  has  been  Mil-Std-1553  (1553). 
Because  it  utilized  a  ‘bus  architecture’  where  all  devices  are  connected  to  a  central  cable, 
monitoring  the  bus  data  for  Test  &  Evaluation  purposes  was  relatively  simple.  Regardless  of 
where  the  bus  tap  was  made,  all  of  the  data  was  available.  The  data  requirements  of  today’s 
aircraft  are  so  large  that  it  overwhelms  the  1553  bus.  For  many  applications,  the  replacement  for 
1553  is  Fibre  Channel,  an  ANSI  standard. 

Fibre  Channel  is  currently  4000  times  faster  than  1553  with  plans  to  go  faster.  Operating  at  this 
speed  means  a  bus  architecture  is  no  longer  feasible.  The  result  is  the  use  of  point-to-point 
architectures.  A  node  on  the  system  will  communicate  through  a  port  with  only  one  other  port. 
Each  node  may  have  multiple  ports  to  create  what  the  industry  terms  a  ‘fabric’.  The  speed  ^d 
architecture  differences  between  1553  and  Fibre  Channel  will  require  the  instrumentation 
community  to  develop  a  new  approach  to  capture  bus  data  under  this  paradigm. 


Application  of  Systems  Engineering 

The  constraints  of  performing  this  project  during  one  semester  with  a  team  of  one,  lead  me  to 
focus  my  efforts  where  I  can  have  the  most  impact  -  the  concept  development  stage. 


1.  Needs  Analysis 

During  needs  analysis,  the  project  will  be  focused  on  identifying  the  rnission  need  and 
translating  the  need  into  operational  requirements.  The  requirements  will  be  translated  into 
functions  and  allocated  to  subsystems.  Operational  risk  will  be  addressed  in  terms  of  flight 
safety  whenever  aircraft  production  systems  may  be  compromised. 

2.  Concept  Exploration 

During  concept  exploration,  the  operational  requirements  will  be  looked  at  in  more  detail 
ensuring  a  complete  picture  independent  of  any  initial  design  concepts.  Performance 
parameters  required  to  meet  the  operational  requirements  will  be  generated.  Multiple  system 
possibilities  will  be  identified 

3.  Concept  Definition 

During  concept  definition,  a  trade  study  will  be  performed  to  determine  the  best  approach. 
The  selected  concept  will  be  analyzed  based  on  the  operational  requirements  to  ensure  it  vdll 
meet  the  need. 


Technical  Approach 

Once  the  proposal  has  been  accepted,  a  mission  needs  statement  (MNS)  will  be  written.  From 
the  MNS,  an  operational  requirements  document  (ORD)  will  be  generated.  Comments  from  the 
three  services  will  be  solicited  to  gain  a  broad  view  of  the  need  and  requirements.  The  ORD  will 
be  supplemented  with  a  concept  of  operations  (ConOps). 

Whenever  an  instrumentation  system  interfaces  to  a  critical  production  system,  a  flight  clearance 
is  needed.  Since  this  will  be  the  first  time  a  networked  avionics  bus  has  been  monitored,  this  will 
be  one  of  the  prime  elements  in  the  risk  analysis.  The  bulk  of  this  research  will  identify  the 
office  that  can  grant  flight  clearances  and  document  what  they  consider  critical.  Unlike  the 
needs  and  requirements,  this  will  be  researched  within  the  Navy  only  in  order  to  limit  the  scope. 

It  is  assumed  gaining  Navy  approval  for  the  system  would  be  similar  for  the  Air  Force  and 
Army. 

Research  into  the  various  possible  system  configurations  will  be  performed  and  documented. 

This  document  will  be  the  basis  for  a  trade  study  to  determine  the  most  effective  solution. 


Milestones 

Project  Start 
Project  Proposal 
Interim  Report 
Final  Report 
Oral  Report 


01  Aug  00 
20  Sep  00 
25  Oct  00 
13  Dec  00 
13  Dec  00 
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1 .  Requirements  .1. 

Given  that  the  1553  has  become  inadequate  for  handling  data  on  military  aircraft,  the  question  is 

how  much  faster  should  a  replacement  be  to  accommodate  the  data  needs  for  the  next  5-10  years. 
Just  because  replacement  by  Fibre  Channel  is  4000  times  faster,  this  does  not  drive  the 

requirement. 

The  airframe  manufacturer  selected  Fibre  Channel  as  the  avionics  bus  based  on  their  needs  and 
insights.  My  requirement  is  to  capture  data  on  the  avionics  system  without  affecting  the  avionics 
system  Since  Fibre  Channel  was  chosen,  that  defines  one  of  the  external  interfaces  of  the  bus 
monitoring  system.  The  fact  that  Fibre  Channel  operates  at  high  speeds  imposes  additional 
constraints  in  how  the  interface  is  approached  (as  opposed  to  the  traditional  method  of  transformer 
coupling  for  1553  bus  monitoring). 

2.  Bus  Architecture  ^  ^ 

If  the  real  requirement  for  operating  speed  is  well  below  the  maximum  speed  of  Fibre  Channel, 
would  bus  architecting  be  feasible?  At  what  speeds  does  bus  architecture  become  inadequate 
and.why?  What  are  the  systems  engineering  implications  of  capturing  a  point-to-point  network? 
How  is  this  more  a  system  than  a  network  design  problem? 

The  discussion  of  bus  architectures  was  to  provide  an  understanding  of  some  of  the  fundamental 
differences  between  1553  and  Fibre  Channel.  A  ‘bus  architecture’  at  gigabit  speeds  would  need  to 
be  kept  very  short  due  to  the  propagation  delays.  (The  clock  period  of  a  bus  operating  at  1  GHz  is 
1  nanosecond.  The  propagation  delay  through  copper  is  on  the  order  of  5  nanoseconds  per  meter.) 
By  the  time  a  test  aircraft  reaches  the  instrumentation  department  for  installation  of  a 
(developmental  test)  data  acquisition  system,  the  choice  of  the  avionics  bus  and  its  architecture  has 
already  been  decided  and  installed.  Since  this  bus-monitoring  unit  would  only  be  used  during  tests, 
the  option  to  change  the  production  avionics  system  is  not  necessarily  available.  Below  is  a  graphic 
showing  functionally  how  the  bus  monitor  system  would  interface  a  production  avionics  system  to  a 
T&E  data  system. 
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3.  In  your  discussion  of  Application  of  System  Engineering  and  Technical  Approach,  you  do  not 
identify  the  substance  of  the  work  but  only  the  generic  terms.  For  instance,  what  will  be  the 
scope  of  your  project  in  terms  of  aircraft  components?  What  are  examples  of  typical  complex 
components?  What  would  you  trade  off?  What  risks  do  you  anticipate? 

The  entire  bus  monitoring  system  will  be  flight  test  components,  (see  the  figure  below)  There  will 
be  data  interfaces  from  the  avionics  and  to  the  data  system.  There  will  also  be  a  format  component 
to  format  the  data  into  something  useful  to  the  data  system.  There  are  two  major  approaches  to 
gathering  the  avionics  data.  The  first  is  to  monitor  each  connection  from  the  nodes  to  the  switch. 
The  second  is  to  replace  the  switch  with  an  instrumentation  “friendly”  switch.  The  trade-offs  are 
avionics  system  integrity,  data  capture  capability,  physical  size,  and  commercial  viability. 

When  capturing  avionics  bus  data,  there  are  two  modes  in  which  to  operate  —  selected  data  and 
100%  data.  Selected  data  is  used  when  a  subset  of  bus  data  is  of  concern.  One  hundred  percent 
data  is  used  when  all  of  the  data  on  the  bus  is  needed  or  the  bus  timing  is  of  concern.  The  avionics 
interface  is  considered  a  complex  component.  Due  to  the  dual  nature  of  bus  data  collection  and 
how  the  data  needs  to  be  formatted  for  each,  the  formatter  is  considered  a  complex  component. 
Since  the  instrumentation  community  has  control  over  the  T&E  data  system,  the  data  system 
interface  is  not  initially  considered  a  complex  component. 

The  first  rule  of  instrumentation  is  to  monitor  what  is  of  interest  without  affecting  the 
measurement.  The  first  rule  of  flight  test  instrumentation  is  to  collect  the  data  without  adding  any 
critical  failure  modes  to  the  aircraft  (instrumentation  failures  causing  the  loss  of  the  aircraft).  The 
major  risk  to  this  project  is  in  finding  an  interface  method  that  won’t  add  any  critical  failure  modes 
to  the  aircraft.  1  don’t  think  that  is  possible,  so  the  second  risk  is  in  identifying  someone  with 
signature  authority  that  will  allow  such  a  system  to  be  installed.  Since  the  first  aircraft  with 
avionics  networks  haven’t  reached  the  Tt&E  ranges  yet,  this  will  most  likely  require  a  paradigm 
shift  from  the  way  business  was  done  in  the  past.  As  a  result,  a  formal  process  of  how  to  get  the 
chosen  interface  method  approved  will  be  identified. 

The  scope  of  the  project  would  be: 

•  Project  need 

•  Operational  requirments 

•  Risk  Assessment 

•  System  concept 

-  Functional  allocation 

-  Avionics  bus  interface 
>*■  Requirements 

Approach  trade-offs 

-  Process  to  get  selected*lnterface  method  approved 

-  Format  of  selected  and  100%  data 
^  Requirements 

^  Trade-off  of  using  a  single  format  or  two  tailored  formats 
^  Conceptual  format  based  on  requirements 

•  Evaluation  of  system  as  defined  against  the  need  and  requirments 
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Project  Objectivips 

Traditionally,  airframes  were  designed  without  any  thought  of  ways  to  instrument  them.  Once 
the  airframe  was  built,  requirements  were  turned  over  to  the  flight  test  instrumentation 
department  to  find  a  way  to  monitor  the  data  necessary  for  testing  (the  term  “afterthought” 
comes  to  mind).  This  was  not  necessarily  a  bad  thing  -  then.  The  economics  was  a  1 0  million- 
dollar  instrumentation  budget  was  noise  to  a  billion-dollar  development  budget.  During  the  past 
8-10  years,  that  has  begun  to  change  for  a  couple  of  reasons.  Defense  dollars  are  diminishing 
while  the  airframes  are  becoming  much  more  complex.  The  result  has  been  a  push-pull  effect  to 
integrate  the  test  instrumentation  engineers  earlier  in  the  program.  The  developer  wants  to  pull 
the  test  instrumentation  engineer  in  to  reduce  overall  development  costs.  The  test 
instrumentation  engineer  wants  to  push  their  way  in  to  minimize  unnecessary  instrumentation 
complexity  during  Test  and  Evaluation  (T&E). 

The  current  state  of  the  art  has  airframe  developers  augmenting  the  production  avionics  data 
buses  with  high-speed  fiber  optic  networks  (in  many  cases  using  Fibre  Channel).  As  these  fiber 
optic  networks  are  being  installed  in  airframes,  the  test  instrumentation  engineer  will  be  expected 
to  safely  monitor  the  data  flowing  through  them.  Unlike  many  of  the  systems  in  the  past, 
successful  monitoring  will  require  an  engineering  analysis  way  before  any  data  is  required.  The 
timing  for  this  project  is  perfect.  Networks  are  now  being  put  in  several  of  the  major  airfi-ames 
where  the  designs  could  be  tweaked  to  facilitate  the  instmmentation  system.  These  systems  are 
far  enough  down  the  road  that  knowledge  gained  now  will  help  the  community  prepare. 

There  is  no  funding  currently  identified  for  this  task.  The  concept  was  submitted  through  the 
Small  Business  Innovative  Research  (SBIR)  programs  office  last  year,  but  did  not  receive 
funding.  Through  this  project,  I  expect  to  lay  the  groundwork  for  an  avionics  bus  monitor 
development  program  by  performing  the  initial  system  engineering  by  developing  a  system 
specification.  The  final  report  will  be  cleared  for  public  release  to  be  used  as  part  of  a 
company’s  Internal  Research  and  Development  (IRAD)  program  or  the  baseline  for  a  SBIR 
program. 


Need  for  System 

Acquisition  Reform  has  allowed  the  DoD  to  quickly  integrate  state  of  the  art  commercial 
products  into  the  weapons  platforms.  One  such  area  is  the  integration  of  commercial  network 
technology  into  the  production  avionics  suite.  There  is  a  concern  this  is  happening  faster  then 
the  Test  and  Evaluation  community  can  react  with  proper  instrumentation  practices  and  products. 

For  the  past  20  years,  the  avionics  bus  used  on  military  aircraft  has  been  Mil-Std-1553  (1553). 
1553  utilized  a  ‘bus  architecture’  where  all  devices  are  connected  to  a  central  cable  that  made 
monitoring  the  bus  data  for  Test  &  Evaluation  purposes  relatively  simple.  Regardless  of  where 
the  instrumentation  system  tapped  the  bus,  all  of  the  data  was  available.  Due  to  the  low  data 
rate,  the  tap  was  transformer  coupled  which  provided  isolation  from  the  instrumentation  system. 
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The  data  requirements  of  today’s  aircraft  are  so  large  that  it  overwhelms  the  1553  bus.  ^  For  many 
airframe  manufacturers,  the  replacement  for  1553  is  Fibre  Channel,  an  ANSI  standard. 

Fibre  Channel  is  currently  4000  times  faster  than  1553  with  plans  to  go  faster.  Fiber  Channel 
operates  in  a  point-to-point  architecture.  A  node  on  the  system  will  communicate  through  its 
port  with  only  one  other  port.  Special  units  called  ‘switches’  receive  data  on  one  port  and  send 
data  out  on  another  port  to  create  what  the  industry  terms  a  ‘fabric’.  The  speed  and  architecture 
differences  between  1553  and  Fibre  Channel  require  the  instrumentation  community  to 
determine  a  new  approach  to  capture  bus  data. 

The  proposed  bus  monitor  system  must  be  capable  of  monitoring  any  data  on  the  production 
avionics  system  and  direct  the  data  of  interest  into  the  T&E  data  system  .  See  Figure  1.  It  must 
do  this  without  compromising  the  data  quality  of  the  avionics  system  (i.e.  affecting  the  data 
values  or  degrading  the  operation  of  the  bus).  A  failure  of  the  bus  monitor  system  or  the  T&E 
data  system  should  not  cause  degradation  of  the  production  avionics  bus. 


Figure  1  System  Relationships 


'  Fibre  Channel  can  utilize  either  copper  wire  or  fiber  optic  cables.  ^ 

'  A  T&E  Data  System  is  a  system  that  monitors  data  during  the  T&E  development  phase.  This  data  is  recorded 
and/or  transmitted  to  a  ground  processing  facility  for  in-flight  data  monitoring.  As  such,  the  T&E  data  system 
cannot  interfere  with  any  production  systems.  The  T&E  data  system  consists  of  independent  winng,  data 
acquisition  units,  and  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed. 
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Description  of  Products 

Throughout  this  project,  work  will  be  accomplished  on  the  following  deliverables.  A  rough 
breakdown  of  each  deliverable  is  listed  below. 

Statement  of  Need 

The  statement  of  need  will  provide  background  to  the  problem  and  address  the  need  for 
this  project  with  input  from  the  three  services. 

System  Requirements  Document 

The  system  requirements  document  will  address  the  tri-service  requirements  through 
questionnaires  and  several  follow-up  interviews.  A  Concept  of  Operations  (ConOps)  will 
be  produced  to  ensure  all  modes  of  operation  and  environments  are  addressed.  Interface 
Control  Documents  (ICDs)  will  be  written  for  the  external  interfaces  and  the  system  and 
data  requirements  will  be  identified.  A  requirements  validation  will  be  performed. 

Trade  Studies 

Two  trade  studies  are  planned.  The  first  trade  study  involves  the  method  of  externally 
‘tapping’  into  the  avionics  bus  to  gather  data.  Some  of  the  elements  that  will  be  traded 
include  -  failure  modes  added  to  the  avionics  bus;  flight  safety  approval;  commercial 
availability;  and  size.  Once  the  test  community  is  comfortable  that  the  avionics  bus  and 
T&E  data  systems  are  performing  as  they  should,  the  possibility  of  being  part  of  the 
system  rather  than  external  to  it  can  be  entertained.  The  second  trade  study  will  use  the 
most  viable  approach(es)  from  the  first  trade  study  and  add  several  alternatives  with  the 
data  system  an  integral  part  of  the  avionics  system. 

Interim  Report 

The  Interim  Report  will  provide  a  detailed  snapshot  of  the  project  status  to  date.  It  will 
include  a  detailed  project  description,  the  requirements  document,  a  draft  of  the  trade 
studies,  and  an  updated  schedule  and  risk  assessment. 

System  Specification  ('A-Specl 

The  system  specification  provides  a  mechanism  to  roll  much  of  the  initial  systems 
engineering  performed  on  this  project  into  a  single  concise  document.  This  document 
will  be  used  as  a  basis  ^or  subsequent  contract  efforts. 

Final  Report 

The  final  report  is  the  culmination  of  the  project.  Besides  final  versions  of  the  system 
engineering  tasks  performed  throughout,  it  will  include  the  project  evaluation  and 
conclusions/recommendations. 

Oral  Report 

The  oral  report  is  an  hour-long  discussion  of  the  project  as  a  whole  as  well  as  the  lessons 
learned  during  the  project. 
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Application  of  Systems  Engineering 

The  constraints  of  performing  this  project  during  one  semester  with  a  team  of  one,  lead  me  to 
focus  my  efforts  where  I  can  have  the  most  impact  -  the  concept  development  stage. 

Requirements  Analysis 

•  Develop  a  statement  of  need 

•  Define  concept  of  operations 

•  Identify  Measures  of  Effectiveness  (MOE’s) 

•  Define  the  system  boundaries 

•  Define  the  functional  and  performance  requirements 

•  Validate  the  requirements 

Functional  Analysis  and  Allocation 

•  Define  functional  flow  block  diagram  (FFBD) 

•  Define  system  data  flow  diagram 

•  Define  work  breakdown  structure 

Conceptual  Design 

•  Perform  feasibility  analysis  on  alternative  solutions 
Trade-off  Studies 

•  Perform  trade  study  on  various  methods  of  externally  tapping  into  the  avionics  system 

-  Individual  taps  at  each  node 

-  Production  switch  wdth  instrumentation  port(s) 

-  Replace  production  switch  with  instrumentation  switch 

•  Look  at  alternatives  of  tapping  into  bus  externally  or  become  part  of  the  avionics  system 

-  Use  best  alternatives  fi'om  first  study 

-  Add 

^  Change  production  software  load  to  direct  data  to  instrumentation  port 
^  Require  avionics  boxes  have  extra  external  port 

Risk  Assessment  and  Risk  Reduction 

•  Assess  operational  risk  to  avionics  system 

•  Assess  data  risk  of  introducing  errors  with  monitoring  equipment 

•  Assess  program  risk  of  getting  approval  from  ‘Flight  Safety’ 

System  Evaluation 

•  Evaluate  trade  study  winner  against  need  and  requirements 

•  Write  system  spec 


5 


Fibre  Channel  Avionics  Bus  Monitor 


Technical  Approach  and  Scope 

With  the  advent  of  airframe  manufacturers  using  commercial  network  technology  as  part  of  the 
production  avionics  system,  the -instrumentation  community  has  foreseen  the  need  to  monitor 
these  new  busses.  This  project  will  take  the  gut  feeling  that  something  must  be  done  before  the 
aircraft  shows  up  at  our  doorstep  and  create  a  statement  of  need  based  on  a  sampling  of  users 
throughout  the  DoD.  The  statement  of  need  will  guide  the  development  of  operational  scenarios 
and  requirements. 

Whenever  an  instrumentation  system  interfaces  to  a  critical  production  system,  a  flight  clearance 
is  needed.  Since  this  will  be  the  first  time  a  networked  avionics  bus  has  been  monitored,  flight 
clearance  issues  will  be  the  prime  element  in  the  operational  risk  analysis.  The  bulk  of  this 
research  will  identify  the  office  that  can  grant  flight  clearances  and  document  what  they  consider 
critical.  Unlike  the  needs  and  requirements,  this  will  be  researched  within  the  Navy  only  in  order 
to  limit  the  scope.  It  is  assumed  the  process  to  gain  Navy  approval  for  the  system  would  be 
similar  for  the  Air  Force  and  Army. 

There  are  two  reasons  to  gather  data  fi’om  the  production  avionics  bus.  The  first  is  when  you  are 
validating  the  bus  --  you  want  to  make  sure  the  data  on  the  bus  is  correct.  In  this  case,  the  data 
system  must  be  independent  of  the  avionics  system.  The  first  trade  study  will  consider  the 
options  available  in  this  scenario.  The  second  reason  to  gather  bus  data  is  when  the  data  is 
needed  as  truth  data.  The  bus  data  is  used  to  validate  a  separate  subsystem.  The  independence 
of  the  data  system  is  less  critical  in  this  case.  Once  airframes  are  validated,  this  is  the  long-term 
case.  The  second  trade  study  will  consider  all  ways  of  gathering  data  from  the  bus  including  the 
best  cases  from  the  first  trade  study  and  situations  where  the  data  system  is  part  of  the  avionics 
system.  The  trade  elements  will  be  slightly  different  in  the  second  study.  While  the  first  will 
focus  mostly  on  getting  the  job  done,  the  second  will  focus  more  on  the  long-term  costs. 

The  system  engineering  products  produced  during  this  project  will  be  included  by  reference  or 
attachment  in  the  system  specification.  The  system  specification  will  be  the  basis  for  follow  on 
funding  avenues. 

Resource  Requirements 

Standard  office  equipment  (computer  w/  internet  access,  desk,  phone) 

-  ANSI  Fibre  Channel  standards 

-  Access  to  Fibre  Channel  Avionics  Personnel 

-  Primarily  Fibre  Channel  Avionics  Environment  Working  Group 

-  Mike  Foster,  Boeing  -  Seattle  -  Bob  Pederson,  General  Dynamics 

-  Steve  Wilson,  Boeing  -  St.  Louis  -  Gary  Warden,  SRB  Consulting 

-  Access  to  Flight  Safety  Personnel 

-  Access  to  advisor 

-  Access  to  user  community 

-  Tim  Chalfant,  Edwards  AFB  -  Dan  Skelley,  Naval  Air  Warfare  Center 

-  Kip  Temple,  Edwards  AFB  -  Sam  Mardemess,  Aberdeen  Proving 

-  Rob  Crist,  Eglin  AFB  Grounds 

-  Time 
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Task  Breakdown 

Fibre  Channel  Avionics  Bus  Monitor 

1 .  Write  Concept 

2.  Write  Proposal 

3.  Needs  analysis 

3.1.  Evaluate  current  state  of  the  art  avionics  bus  architectures 

3.2.  Poll  user  groups 

3.3.  Write  statement  of  need 

4.  Requirements  Analysis 

4.1.  Concept  of  Operations 

4.1.1.  Define  Operational  Scenarios 

4. 1 .2.  Define  the  Boundaries  of  the  System 

4.1.3.  Write  concept  of  operations 

4.2.  Identify  external  interfaces  and  write  appropriate  interface  control  documents 

4.3.  Gather  data 

4.3.1.  Write  questionnaire  and  conduct  interviews 

4.3.2.  Reduce  data 

'4.4.  Ideritify/document  process  to  get  selected  interface  method  approved 

4.5.  Identify  system  requirements 

4.6.  Identify  data  requirements 

4.7.  Write  requirements  document 

5.  Trade  Studies 

5.1 .  Bus  tapping  method 

5.1.1.  Establish  criteria 

5.1.2.  Identify  possible  methods 

5.1.3.  Research  each  method 

5.1.4.  Write  document 

5.2.  Avionics  data  acquisition  approach 

5.2.1.  Establish  criteria 

5.2.2.  Identify  possible  methods 

5.2.3.  Research  each  method 

5.2.4.  Write  document 

6.  Interim  Report 

7.  System  Spec 

7.1.  Create  document  outline 

7.2.  Write  document  scope  and  system  overview 

7.3.  Write  system  requirements  section 

7.4.  Finalize  document 

7.5.  Update  Needs/Requirements  documents 

8.  Final  Report 
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Fibre  Channel  Avionics  Bus  Monitor 


Risk  Assessment 


Prob 

Severity 

Risk 

Interacting  with  new  advisor 

i 

11 

Mitigator 

Face  to  face  meeting;  email/phone  communication 

Status 

Open 

Risk 

Not  meeting  user's  needs  and  requirements 

Med 

High 

Mitigator 

Interview  users,  provide  draft  documents  to  users  for 
feedback 

/:::Statiis>'' ’ 

Open 

IHsk 

Not  understanding  operational  environment 

Med 

Med 

Mitigatioir 

Use  previous  bus  monitors  (1553)  as  a  model,  talk  to 
knowledgeable  people. 

Status 

Open 

Not  understanding  network  aspect  of  avionics 

High 

■ 

High 

Mitigator 

Get  knowledgeable  people  involved  (fibre  channel  and 
avionics).  Do  research. 

Status 

Open 

Risk 

Trade  Study:  Don’t  include  viable  option  or  don't  throw  out 
non-viable  option 

High 

Med 

Mitigator 

Get  knowledgeable  people  involved  (fibre  channel  and 
avionics).  Do  research. 

Status 

Open 

Risk 

Fall  behind  on  schedule  due  to  workload,  travel,  family 

i 

Med 

Low 

Mitigator 

Produce  realistic  schedule.  Work  to  get  ahead  when 
possible.  Identify  critical  path. 

Status 

Open 

Risk 

Unknown  -  unknowns 

Med 

High 

Mitigator 

Perform  risk  assessment  periodically.  Keep  looking  for 
potential  risk  areas 

Status 

Open 
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Scope  - 

This  statement  of  need  is  concerned  with  the  Test  and  Evaluation  (T&E)  organizations'  need  to 
monitor  data  from  the  production  avionics  bussed  on  various  weapons  platforms.  The 
requirements  for  monitoring  bus  data  change  throughout  the  life  of  the  platform  as  the  nature  of 
the  tests  change  from  validating  the  bus  to  using  the  bus  as  a  truth  source.  The  need  will  be 
considered  from  the  perspective  of  the  weapons  platform  lifecycle. 

Background 

A  T&E  Data  System  acquires  data  during  a  test  or  mission.  This  data  is  recorded  for  post-flight 
analysis.  The  data  may  also  be  transmitted  to  a  ground  processing  facility  for  in-flight  data 
monitoring.  As  such,  the  T&E  data  system  must  be  invisible  to  the  operation  and  control  of  the 
aircraft.  The  T&E  data  system  typically  consists  of  independent  wiring,  data  acquisition  units, 
and  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed  and  the  aircraft  is 
returned  to  fleet  status.  The  data  system  may  also  be  known  as  an  instrumentation  system  or  a 
telemetry  system. 

For  the  past  20  years,  the  avionics  bus  used  on  military  aircraft  has  been  Mil-Std-1553  (1553). 
Much  of  the  data  sent  across  the  1553  bus  is  of  interest  to  the  test  program.  As  can  be  seen  in 
Figure  1,  a  bridging  system  was  used  that  would  gather  the  data  of  interest  from  the  production 
avionics  system  and  format  the  data  into  something  useful  for  the  T&E  data  system. 


Figure  1  System  Relationships 


The  1553  standard  utilizes  a  ‘bus  architecture’  where  all  devices  or  remote  terminals  (RT)  are 
connected  to  the  bus  controller  (BC)  via  a  central  cable  as  shown  in  Figure  2.  Regardless  of 
where  a  unit  is  connected  to  the  bus,  all  of  the  data  on  the  bus  is  available  to  the  unit.  To 
interface  to  the  1553  bus,  the  bus  monitor  system  used  the  same  method  listed  in  Mil-Std-1553 
that  the  avionics  units  followed.  The  bus  monitor  was  programmed  to  capture  all  of  the  data 
(100%  mode)  or  specific  data  words  (selected  data  mode). 
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Figure  2, 1553  Bus  Architecture 


Basis  for  Need 

Acquisition  Reform  has  allowed  the  Department  of  Defense  (DoD)  to  quickly  integrate  state  of 
the  art  commercial  products  into  weapons  platforms.  One  such  area  is  the  integration  of 
commercial  network  technology  into  the  production  avionics  suite.  The  current  state  of  the  art 
has  airframe  developers  augmenting  the  production  avionics  data  buses  with  high-speed  fiber 
optic  networks  (in  many  cases  using  Fibre  Channel').  Fibre  Channel  is  currently  4000  times 
faster  than  1553  (4  Gbps  vs  1  Mbps)  with  current  plans  to  go  to  10  Gbps.  Fiber  Channel 
operates  in  a  point-to-point  architecture  as  shown  in  Figure  3.  A  node  on  the  system  will 
communicate  through  its  port  with  only  one  other  port.  Special  units  called  ‘switches’  receive 
data  on  one  port  and  send  data  out  on  other  ports  to  create  what  the  industry  terms  a  ‘fabric’. 

T&E  organizations  currently  have  minimal  experience  with  fiber  optic  network  busses.  When 
questioned,  they  expect  their  current  systems  to  be  inadequate  for  the  higher  speeds  and 
architectural  differences  found  in  Fibre  Channel  designs.  They  also  expect  bus  monitor  systems 
for  these  busses  to  be  significantly  different  from  current  practices  and  that  a  significant  safety 
review  of  the  installation  design  will  be  necessary. 


Figure  3,  Fibre  Channel  Switched  Fabric  Architecture 


'  Fibre  Channel  is  an  ANSI  standard  that  can  utilize  either  copper  wire  or  fiber  optic  cables. 


Deficiencies  in  Current  Bus  Monitor  Systems 

The  move  to  network  based,  fiber  optic  avionics  busses  highlight  several  deficiencies  in  the 
current  bus  monitor  Systems  being  used  for  1553.  These  deficiencies  are  of  such  magnitude  that 
merely  upgrading  the  tools  will  not  be  enough.  A  new  approach  must  be  devised  from  the 
ground  up. 

The  easiest  deficiencies  to  grasp  are  the  speed  and  cabling  plant  differences.  1553  operates  at  a 
signaling  rate  of  IMHz.  The  Fibre  Channel  rate  that  most  systems  use  is  1  GHz  -  3  orders  of 
magnitude  higher.  The  Fibre  Channel  specification  currently  tops  out  at  4.25  GHz  with  plans  in 
work  for  10  GHz.  These  speed  differences  alone  invalidate  the  use  of  transformer  coupling  like 
that  currently  used.  Because  Fibre  Channel  has  its  sights  set  on  10  GHz  (and  most  likely  higher 
over  time),  most  of  the  manufacturers  are  installing  fiber  optic  cabling  from  the  outset.  Copper 
wire  can  be  used  at  1  GHz  for  moderate  length  runs.  As  the  rate  rises,  the  copper  runs  get  shorter 
and  require  more  attention  to  impedance  matching  issues. 

One  of  the  more  difficult  issues  to  grasp  is  the  concept  of  a  layered  architecture.  To  put  it  simply, 
a  layered  architecture  breaks  up  the  system  into  distinct  components.  Provided  the  interface 
betAveen  the  components  is  adhered  to,  an  individual  layer  can  be  easily  substituted  with  a  layer 
of  similar  qualities  to  meet  the  current  need.  Most  systems  prior  to  the  network  revolution  used 
monolithic  models.  They  described  everything  from  the  way  the  data  was  formatted  to  the 
encoding  of  the  electrical  signal  on  the  bus.  To  try  a  simple  analogy,  consider  the  differences 
between  a  3-bean  soup  recipe  vice  a  3-bean  soup  kit  (just  add  water).  See  Table  1 .  Current  1553 
bus  monitors  were  designed  around  a  monolithic  1553  specification.  Given  the  major 
differences  in  data  rate  and  format,  the  bus  monitors  can  not  be  cost-effectively  upgraded. 


Table  1,  Layered  Model  Analogy 


Recipe  (Layered  Model) 

Kit  (Monolithic  Model) 

Meeting  yom  needs 

Tailor  recipe  to  your  tastes  or 
needs 

May  have  to  adjust  your  tastes 
to  the  kit 

Availability 

Without  agreements  of  how  to 
tailor,  may  not  get  it  anywhere 
but  home 

The  same  thing  every  time 
regardless  of  who  made  it  or 
where 

If  one  ingredient  is  high 
priced  or  unavailable 

Substitute  for  another  ingredient 

Kit  is  high  priced  or  unavailable 

Non-materiel  Alternatives 

There  are  no  non-materiel  alternatives  considered  to  be  adequate.  The  following  are  alternatives 
that  were  considered. 

Ignore  the  bus,  acquire  data  from  other  means 

The  data  on  the  bus  falls  into  two  categories  -  internal  and  external  avionics  data.  The  external 
data  could  be  acquired  by  installing  transducers  throughout  the  aircraft.  For  some  tests  this 
would  be  preferable.  However  in  general,  it  would  increase  the  long  term  cost  in  both  dollars 
and  down  time  of  the  test  asset  through  duplicating  many  of  the  data  sources  already  on  the  bus. 
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Internal  data  by  definition  comes  from  internal  to  the  avionics  system.  Many  of  these  data  are 
calculated  variables,  status  fields  and  the  like.  The  only  source  of  this  data  is  the  avionics  system 
itself  Without  the  bus,  specific  I/O  would  need  to  be  included  in  the  design  of  all  avionics  units 
just  for  T&E  purposes.  The  cost  would  be  prohibitive  even  if  the  T&E  community  could  drive 
the  requirements  of  a  major  acquisition  program. 

Use  the  same  methods  as  the  manufacturers  when  the  platform  was  originally  designed 
This  is  a  viable  alternative  in  theory,  but  vrith  two  strikes  against  it.  The  first  is  that  each 
manufacturer  is  concerned  with  that  particular  platform.  They  are  not  looking  at  requirements 
across  the  entire  DoD  inventory.  They  need  to  be  price-competitive  therefore  focus  their  efforts 
on  the  requirements  of  that  particular  platform.  The  second  strike  is  their  requirements  are 
focused  with  the  initial  sale  of  the  platform.  The  T&E  organizations  need  to  look  across  the 
lifecycle  of  each  platform.  Timeliness  of  what  the  manufacturers'  are  doing  compovmds  the 
problem.  Until  the  contract  is  awarded,  many  new  platforms  consider  the  avionics  design  a 
competitive  advantage.  This  makes  getting  information  difficult  in  the  early  stages  of  design. 

Choosing  this  alternative  at  face  value  is  not  considered  adequate.  This  alternative  may  require  a 
different  approach  for  each  platform  and  leaves  too  much  to  chance  that  general  T&E  needs  will 
be  met.  However,  each  of  the  manufacturer's  methods  will  be  considered  during  the  later  phases 
of  the  project. 

Potential  Materiel  Alternatives 

Military  Programs 

Military  &  Aerospace  Electronics  Magazine  reported  that  Fibre  Channel  is  part  of  the  design 
baseline  for  avionics  upgrades  in  the  F/A-18,  AH-64,  B-1,  and  the  AWACS.  Fibre  Channel  is 
reportedly  being  considered  for  the  Joint  Airborne  SIGINT  and  the  Joint  Strike  Fighter.  It  is 
expected  that  each  of  these  programs  will  be  able  to  monitor  Fibre  Channel  to  some  degree 
depending  on  the  depth  of  the  avionics  upgrade/design  and  their  ovra  requirements.  The 
specifics  of  these  approaches  should  be  evaluated  as  potential  solutions  to  this  need. 


Vendors 

As  a  result  of  the  programs  mentioned  previously,  it  is  expected  the  majority  will  contract  the 
effort  to  one  or  more  vendors.  The  following  companies  should  be  researched  for  possible 
solutions  based  on  military  program  requirements,  commercial  requirements,  and  in-house 
developments.  This  list  would  include: 


Avionics  component  vendors 

-  DY-4  Systems,  Inc 

-  Data  Device  Corp. 

Instrumentation  vendors 

-  L-3  Communications 

-  Metraplex 
Commercial  Fibre  Channel  vendors 

-  Adaptec  -  Emulex  Network  Systems 

-  Agilent  Technologies  -  Gadzoox  Networks 

_  Ancot  -  McData  Corporation 

-  Brocade  Communications  -  Qlogic 


SBS  Technologies,  Inc 
Systran  Corporation 

SCI  Systems 
Teletronics. 


-  Vixel  Corporation 

-  Xyratex 
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Inter-Service  Cooperation 

Fibre  Channel  will  be  Useful  whenever  an  avionics  bus  must  deal  with_  volumes  of  data  like 
imagery,  radar,  and  sonar.  ^  This  need  is  therefore  not  limited  to  any  one  service  or  any  one- 
platform  type.  This  need  is  shared  by  all  three  services  and  should  be  coordinated  as  such. 

■t'  -  ' :  " 

Potential  Areas  of  Study 

The  single  largest  obstacle  appears  to  be  the  method  of  tapping  into  the  avionics  fiber  optic  cable 
without  adding  undue  failure  modes.  Future  study  should  focus  on  this  area  or  alternate  means 
that  don't  require  a  fiber  optic  tap.  Other  potential  areas  include 

□  Modifying  all  production  avionics  switches  to  allow  test  systems  to  easily  acquire  bus  data. 

□  Modifying  some  production  avionics  switches  that  are  used  in  place  of  the  production  switch 
during  testing. 

□  Develop/purchase  test-only  switches  that  are  used  in  place  of  the  production  switch  during 
testing. 

□  Programming  the  avionics  software  to  send  data  to  a  pre-selected  instrumentation  address. 

□  Requiring  duplicate  ports  on  each  avionics  unit  for  test  purposes. 

Constraints 

Bus  monitor  systems  provide  two  basic  functions  through  the  life  of  a  test  platform.  During  the 
development  and  testing  of  major  bus  modifications,  the  bus  monitor  system  captures  the  state  of 
the  bus  for  bus  validation  purposes.  It  provides  information  about  what  the  platform  thinks  is 
going  to  happen.  This  data  is  correlated  against  other  known  sources.  When  testing  small 
system  updates  or  additions,  the  bus  monitor  is  a  cost-effective  source  of  "truth"  data  from  many 
systems  throughout  the  platform.  A  solution  or  solutions  must  take  both  of  these  functions  into 
account. 

Acquisition  reform  and  the  use  of  commercial-off-the-shelf  (COTS)  have  required  users  take  a 
hard  look  at  the  true  environmental  requirements.  For  many  systems,  the  use  of  COTS  products 
have  provided  cost-effective  solutions.  This  system  must  operate  in  an  airborne  uninhabited 
fighter  environment.  Packaging  and  environmental  issues  must  be  considered  for  any  solution. 

The  goal  of  a  test  system  is  to  acquire  the  data  of  interest  without  affecting  the  system  under  test. 
When  dealing  with  avionics  systems  this  is  especially  true.  Compromising  the  avionics  bus 
could  cause  a  critical  failure.  Currently,  1553  bus  monitor  systems  use  a  passive  bus  coupler  to 
acquire  the  data  from  the  bus.  Given  the  high  data  rates  and  the  use  of  fiber  optics,  the 
requirement  for  an  active  coupler  is  a  distinct  possibility.  Active  couplers  significantly  increase 
the  risk  of  additional  failure  modes  for  the  avionics  bus.  Flight  safety  will  be  a  critical  constraint 
of  any  approach  considered. 

Network  technology  has  been  around  for  years.  Larger  budgets  in  the  past  have  allowed  the 
T&E  community  to  remain  inwardly  focused  by  creating  their  own  standards.  By  controlling  the 
standards,  they  created  a  stable  platform  environment.  With  budgets  on  the  decrease,  more 
pressure  to  utilize  commercial  products,  and  now  networked  based  avionics  busses,  the  T&E 
commimity  can  no  longer  avoid  the  network  issue.  There  is  a  small  number  of  T&E  personnel 
that  see  many  benefits  with  the  use  of  networks.  These  people  are  raising  awareness  of  T&E 
network  issues  --  both  promises  and  problems.  The  concern  is  that  few  people  with  a 
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respectable  knowledge  of  T&E  data  systems  have  more  than  a  casual  knowledge  of  networks  and 
how  to  apply  it.  This  small  cadre  of  network-knowledgeable  people  is  the  ones  that  must  judge 
the  merits  of  a  bus  monitor  approach.  What  makes  this  difficult,  is  thes&  people  are  not  easy  to 
find.  They  are  not  necessarily  T&E  personnel,  heads  of  organizations,  'gray  beards',  or  yoxmg 
techno-junkies. 


References 

There  are  four  major  T&E  Ranges  where  the  majority  of  avionics  bus  testing  is  accomplished: 
Naval  Air  Warfare  Center  (Patuxent  River  and  China  Lake),  Edwards  Air  Force  Base,  and  Eglin 
Air  Force  Base.  The  following  people  were  contacted  for  input  to  this  document  since  they  were 
in  positions  that  allowed  them  a  longer-term  view.  Validation  of  this  need  is  expected  to  exceed 
this  initial  group. 

a  Rob  Crist,  Supervisor,  FI  5  Systems  Engineering  of  the  Instrumentation  Division,  Eglin  AFB 
□  Dan  Skelley,  Deputy  Director,  Test  Article  Preparation.  Naval  Air  Warfare  Center 
O  Tim  Chalfant,  Chief,  Instrumentation  development  branch,  Edwards  Air  Force  Base 
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1  Scope 

1.1  System  Overview 

This  document  pertains  to  a  proposed  Fibre  Channel  Bus  Monitor.  This  bus  monitor  is  used  to 
monitor  Fibre  Channel  avionics  busses  located  on  weapons  platforms  for  test  and  evaluation 
(T&E)  purposes  -  primarily  during  developmental  testing. 

Currently  most  weapons  platform  avionics  busses  use  Mil-Std-1553  (1553).  1553  is  a  military 
standard  that  was  developed  in  the  1970’s.  It  has  worked  exceptionally  well  and  won’t  be 
completely  replaced  for  a  long  time.  However,  at  a  signaling  rate  of  1  MHz,  it  is  showing  its 
age.  Fibre  Channel  is  a  commercial  standard  having  a  much  larger  bandwidth  than  1553 
(lOOOx).  Many  avionics  system  designers  are  upgrading  their  avionics  systems  to  include  Fibre 
Channel  support  for  data  intensive  sensors  like  radars,  infrared,  and  video. 

1.2  Document  Overview 

The  purpose  of  this  document  is  to  describe  the  state  of  current  systems,  the  concept  envisioned 
for  the  new  system,  how  the  new  system  will  be  used,  and  the  impacts  it  may  have  on  current 
operating  procedures. 

2  Referenced  Documents 

2.1  Project  Documents 

Fibre  Channel  Avionics  Bus  Monitor  Proposal,  October  1, 2000 

Fibre  Channel  Avionics  Bus  Monitor  Statement  of  Need,  October  30, 2000 


2.2  Interface  Documents 


Mil-Std-1553BNOT4 

AOO.OO-COOIB 
IRIG  Standard  106-00 
ANSI  X3. 230- 1994 

ANSI  X3.297-1997 

ANSI  X3 .303- 1998 

ANSI  X3. 272- 1996 

ANSI  X3.nnn-200x 
ANSI  X3.nnn-200x^ 
ANSI  X3.nnn-200x'' 


Aircraft  Internal  Time  Division  Command/Response  Multiplex  Data 
Bus,  15-Jan-96 

CAIS  Bus  Interface  Standard,  lO-Sep-99 
Telemetry  Standards,  January  2000 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  (FC-PH),  1994 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  2  (FC-PH-2),  1997 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  3  (FC-PH-3),  1998 

Information  Technology  -  Fibre  Channel  Arbitrated  Loop  (FC-AL), 
1996 

Fibre  Channel  Avionics  Environment  Technical  Report  (due  12/00) 
Information  Technology  -  Fibre  Channel  -  Physical  Interfaces  (FC-PI) 
Information  Technology  -  Fibre  Channel  -  Framing  and  Signaling 
(FC-FS) 


*  FC-PI  and  FC-FS  are  currently  in  work  and  will  supercede  FC-PH,  FC-PH-2,  and  FC-PH-3 
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3  Current  System  or  Situation 

3.1  Background,  Objectives,  and  Scope 

A  T&E  Data  System  acquires  data  during  a  test  or  mission.  This  data  is  recorded  for  post-flight 
analysis.  The  data  may  also  be  transmitted  to  a  ground  processing  facility  for  in-flight  data 
monitoring.  As  such,  the  T&E  data  system  must  be  invisible  to  the  operation  and  control  of  the 
aircraft.  The  T&E  data  system  typically  consists  of  independent  wiring,  data  acquisition  units, 
and  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed  and  the  aircraft  is 
returned  to  fleet  status.  The  data  system  may  also  be  known  as  an  instrumentation  system  or  a 
telemetry  system. 

For  the  past  20  years,  the  avionics  bus  used  on  military  aircraft  has  been  Mil-Std-1553  (1553). 
Much  of  the  data  sent  across  the  1 553  bus  is  of  interest  to  the  test  program.  As  can  be  seen  in 
Figure  1,  a  bridging  system  was  used  that  would  gather  the  data  of  interest  from  the  production 
avionics  system  and  format  the  data  into  something  useful  for  the  T&E  data  system. 


Figure  1  System  Relationships 


1553  utilizes  a  ‘bus  architecture’  where  all  devices  or  remote  terminals  (RT)  are  connected  to  the 
bus  controller  (BC)  via  a  central  cable  as  shown  in  Figure  2.  Regardless  of  where  a  unit  is 
connected  to  the  bus,  all  of  the  data  on  the  bus  is  available  to  the  unit.  To  interface  to  the  1553 
bus,  the  bus  monitor  system  used  the  same  method  listed  in  Mil-Std-1553  that  the  avionics  units 
followed.  The  bus  monitor  was  programmed  to  capture  all  of  the  data  (100%  mode)  or  specific 
data  words  (selected  data  mode). 

Bus  monitor  systems  are  usually  part  of  a  larger  T&E  data  system.  The  T&E  data  system  is 
installed  on  the  test  vehicle  to  gather  data  describing  the  state  of  the  test  vehicle  at  any  given 
moment.  The  data  system  will  gather  data  from  many  different  systems  including  both 
production  and  test  systems.  The  avionics  bus  monitor  is  but  one  data  source.  The  data  is 
transmitted,  recorded  or  both. 
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The  most  common  military  avionics  bus  monitored  by  the  T&E  community  is  Mil-Std-1553 
(1553).  Current  1553  bus  monitor  systems  acquire  the  data  of  interest  on  the  1553  bus  and  pass 
it  on  to  the  T&E  data  system.  The  objective  of  the  1553  bus  monitor  is  to  monitor  the  1553  data 
without  compromising  the  integrity  of  the  avionics  bus.  A  typical  1553  bus  monitor  system 
includes  the  bus  tap  (the  1553  avionics  interface),  the  central  unit  where  the  data  is  formatted,  the 
program  is  stored,  and  the  data  system  interface  is  located,  (reference  Figure  2) 


Figure  2  1553  Bus  Monitor  System  Context 

3.2  Operational  Policies  and  Constraints 

Although  there  are  always  exceptions,  in  general,  the  1553  bus  monitor  must  adhere  to  the 
following  constraints 

•  Must  adhere  to  the  1 553  standard  in  a  receive  only  mode. 

•  Must  not  interfere  with  normal  operation  of  the  1553  bus. 

•  Must  not  introduce  additional  failure  modes 

3.3  Description  of  Current  System 

3.3.1  Operational  Environment 

The  system  operates  in  an  airborne  uninhabited  fighter  environment.  This  implies  a  rugged 
environment  with  tolerances  toward  higher  shock,  vibration,  temperature  extremes,  humidity, 
etc.  Its  use  on  test  vehicles  requires  a  small  volume  to  allow  installation  in  space  constrained 
environments. 
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3.3.2  Major  System  Components 

The  physical  configuration  between  manufacturers  of  1553  bus  monitors  may  vary.  However,  in 
general  they  are  fairly  consistent  with  two  main  components.  The  two  components  are  depicted 
in  Figure  2. 

•  1553  Interface(s)  also  known  as  1553  bus  taps.  A  test  article  may  have  one  or  more  1553 
busses.  Some  systems  have  as  high  as  14.  Depending  on  the  test,  not  all  1553  busses  may 
need  to  be  monitored. 

•  Central  Unit.  The  central  unit  performs  four  main  functions.  The  pre-programmed 
instructions  of  what  data  is  of  interest  is  stored  during  system  setup.  During  operation,  the 
bus  data  being  received  across  the  1553  interface  is  compared  to  the  instruction  set  stored  in 
memory.  The  data  that  is  of  interest  is  formatted  into  a  message  that  is  transmitted  across  the 
data  system  interface  to  the  data  system. 

-  Program  storage  -  Memory  to  which  the  user  uploads  operational  instructions. 

-  Data  comparator  -  Compares  incoming  data  messages  to  instructions  in  program  storage. 

-  Data  Message  Formatter.  -  Formats  selected  data  into  a  data  system  message  structure. 

-  Data  system  interface  -  Physical  interface  into  the  data  system. 

•  Programming  Software.  This  software  may  be  a  standalone  program  or  a  part  of  the  overall 
data  system  software.  The  software  provides  an  interface  that  allows  the  user  to  select  the 
data  of  interest.  The  software  uploads  the  instructions  into  the  program  storage  memory  via 
the  data  system  interface. 

3.3.3  Interfaces  to  External  Systems  or  Procedures 

There  are  two  major  external  interfaces.  They  are  the  1 553  bus  interface  and  the  data  system 
interface.  The  1553  interface  is  controlled  by  Mil-Std-1553.  Many  times  these  bus  monitor 
systems  are  part  of  a  bigger  data  system  that  was  developed  by  a  single  vendor  and  may  be 
proprietary.  In  recent  years,  the  Common  Airborne  Instrumentation  System  (CAIS)  bus  has  tried 
to  change  this  situation  by  establishing  the  CAIS  Bus  Interface  Standard.  For  these  data  systems, 
the  CAIS  Bus  Interface  Standard  controls  the  data  system  interface. 

As  stated  previously,  these  systems  need  to  be  programmed  before  they  are  useful  -  as  is  the  case 
with  most  data  system  components.  Many  of  the  data  systems  require  some  coordination 
between  the  bus  monitor  system  and  the  data  system  controller  (DSC).  In  these  systems,  the  bus 
monitor  will  acquire  the  data  according  to  its  program  load  and  store  the  values  in  memory. 
When  the  system  controller  is  ready  for  the  data,  it  will  query  specific  addresses  in  the  bus 
monitor.  The  majority  of  bus  monitors  are  sub-systems  to  larger  data  systems.  The  hand-off  of 
data  addresses  in  the  bus  monitor  to  the  DSC  is  handled  by  a  single  integrated  software  program. 

3.3.4  Canabilities/Functions  of  the  Current  System 

Current  1553  bus  monitor  systems  operate  in  two  modes:  Selected  Data  Acquisition  and  100% 
Bus  Capture.  These  modes  typically  operate  independent  of  each  other,  mostly  due  to  bandwidth 
issues.  Figure  3  shows  a  typical  data  system.  Whereas  a  single  bus  monitor  can  interface  up  to  8 
1553  busses,  one  is  shown  in  the  figure  for  simplicity.  The  1553  bus  monitor  system  (BMS) 
monitors  the  data  flowing  through  the  1553  production  avionics  system.  According  to  the 
program  stored  in  the  1553  BMS,  selected  data  is  stored  in  memory.  If  100%  acquisition  is 
enabled,  the  1553  BMS  also  formats  the  entire  1553  bus  data  stream  and  outputs  it  directly  to  the 
recorder.  The  Data  System  Controller  (DSC)  queries  all  of  the  data  acquisition  units  for  specific 
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data  according  to  its  programmed  instructions.  The  DSC  formats  this  data  and  sends  it  to  the 
recording  system  and  the  transmitter  system.  Due  to  telemetry  bandwidth  constraints,  this 
selected  data  output  is  usually  a  much  lower  rate  than  the  100%  1553^  output  (1  Mbps  vs  16 
Mbps  for  100%  of '8  1553  Jbusses). 


Figure  3  Typical  Data  System 

3.4  Users  or  Involved  Personnel 

There  are  four  types  of  users  involved  with  operating  this  product.  In  some  organizations,  a 
single  individual  could  accomplish  more  than  one  function.  For  each  of  these  user  types, 
organizations  may  require  additional  coordination  or  oversight.  For  example,  a  system  installer 
may  require  structural  approvals  prior  to  installation  and  inspection  prior  to  flight. 

□  Instrumentation  Engineer  -  This  person  understands  the  technical  details  of  the  capabilities 
of  this  system  and  how  they  relate  to  the  requirements  the  data  system  must  fulfill  overall. 
This  person  is  responsible  for  programming  the  system  to  obtain  the  desired  performance. 
This  person  is  also  involved  with  the  installation  of  the  BMS  insofar  as  where  it  will  be 
located  and  what  wiring  needs  to  be  run  to  support  it. 

□  System  Installer  -  This  person  physically  installs  the  imit  into  the  test  article  in  the  location 
the  engineer  has  identified.  This  person  has  direct  knowledge  (or  a  support  structure)  of 
structures  and  mechanical  design  to  ensure  the  BMS  is  installed  in  a  safe  manner  relative  to 
the  vehicle’s  environment  to  which  it  is  installed. 

□  Cable  Installer  -  This  person  physically  installs  the  wiring  as  identified  by  the  engineer. 
This  person  has  the  knowledge  of  how  to  properly  route  and  constrain  the  wire  runs 
throughout  a  given  test  vehicle. 

a  Test  Operator  -  The  test  operator  is  the  person  actually  performing  the  test.  Dependent 
upon  the  type  of  test,  this  could  be  a  pilot,  driver,  or  lab  technician.  This  person  has  no 
detailed  knowledge  of  the  BMS  or  its  capabilities.  The  extent  of  operator  involvement  is 
limited  to  an  overall  data  system  power  switch. 


5 


3.5  Support  Concept 

The  details  of  the  support  concept  employed  by  each  organization  vary.  This  is  based  largely  on 
how  they  are  funded,  the  number  of  systems  fielded  on  daily,  monthly  or  annual  basis,  and  their 
relationship  with  their  customer.  What  is  common  is  the  fact  that  BMS  are  commercial  products. 
Any  repairs  or  replacements  are  handled  directly  with  the  factory.  This  implies  that  each 
organization  have  some  contract  mechanism  available  to  reach  that  particular  vendor. 


4  Justification  for  and  Nature  of  Changes 

4.1  Justification  for  Change 

The  move  to  network  based,  fiber  optic  avionics  busses  highlight  several  deficiencies  in  the 
current  bus  monitor  systems  being  used  for  1553.  These  deficiencies  are  of  such  magnitude  that 
merely  upgrading  the  tools  will  not  be  enough.  A  new  approach  must  be  devised  from  the 
ground  up. 

The  easiest  deficiencies  to  grasp  are  the  speed  and  cabling  plant  differences.  1553  operates  at  a 
signaling  rate  of  IMHz.  The  Fibre  Channel  rate  that  most  systems  are  considering  as  a  baseline 
is  1  "GHz  -  3  orders  of  magnitude  higher.  The  Fibre  Channel  specification  currently  tops  out  at 
4.25  GHz  vdth  plans  in  work  for  10  GHz.  These  speed  differences  alone  invalidate  the  use  of 
transformer  coupling  like  that  currently  used.  Because  Fibre  Channel  has  its  sights  set  on  10 
GHz  (and  most  likely  higher  over  time),  most  of  the  manufacturers  are  installing  fiber  optic 
cabling  from  the  outset.  Copper  wire  can  be  used  at  1  GHz  for  moderate  length  runs.  However, 
as  the  rate  rises,  the  copper  runs  get  shorter  and  require  more  attention  to  impedance  matching 
issues. 

The  bus  topology  has  significantly  changed  with  Fibre  Channel.  1553  used  a  bus  topology.  All 
traffic  was  sent  across  a  media  who  was  common  to  all  terminals.  A  single  1553  tap  could 
monitor  all  of  the  data  on  the  bus.  The  Fibre  Channel  topology  is  called  a  switched  Fabric 
(reference  section  8.1.2  for  additional  information).  With  a  switched  Fabric,  a  node  'will  send  its 
information  to  the  switch;  the  switch  in  turn  sends  the  data  to  the  appropriate  node  based  on  the 
address  of  the  data  packet.  With  Fibre  Channel  operating  at  such  high  speeds,  the  probability  of 
running  fiber  optic  cables,  and  a  different  bus  topology,  the  old  method  of  tapping  into  a  bus  'will 
not  work.  The  question  of  how  to  tap  into  the  bus  will  require  a  lot  of  thought  as  to  what  can  be 
done  and  a  lot  of  discussion  as  to  what  should  be  done. 

4.2  Description  of  Needed  Changes 

Given  the  deficiencies  listed  in  4.1,  an  approach  to  monitor  Fibre  Channel  avionics  busses  must 
be  devised.  The  approach  will  consist  of  a  method  to  electrically  (optically)  interface  to  the 
avionics  bus  and  provide  the  necessary  data  to  satisfy  the  performing  organization’s  flight  safety 
requirements.  The  approach  must  satisfy  the  operational  scenarios  listed  in  section  6  while 
minimizing  any  failure  modes  added  to  the  avionics  bus  as  a  result  of  the  interface  method. 

4.3  Priorities  Among  the  Changes 

□  The  first  priority  is  flight  safety.  Any  approach  must  be  considered  ‘safe’.  Safe  in  this  case 
is  defined  as  having  no  vmdue  level  of  risk.  Each  organization  must  address  acceptable  risk 
in  their  own  terms  according  to  their  mission,  experience,  and  capabilities. 
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□  The  second  priority  is  data  integrity.  Data  that  is  corrupted  by  the  test  system  is  of  no  value. 

□  The  third  priority  is  a  tradeoff  between  capability  and  cost. 

4.4  Changes  Considered  but  not  Included 

There  were  no  changes  considered  that  were  not  included. 

4.5  Assumptions  and  Constraints 

There  is  no  constraint  limiting  the  bus  monitor  approach  to  only  one  method.  Although  a  single 
method  that  meets  all  requirements  would  generally  be  superior  from  many  aspects,  it  may  be 
too  expensive  for  the  majority  of  applications.  A  two  or  even  three  method  approach  may  be 
more  cost  effective  overall,  thus  more  desirable. 

It  is  assumed  the  paradigm  for  acquiring  data  from  avionics  busses  has  not  changed  with  the 
introduction  of  high-speed  network  busses  like  Fibre  Channel.  Data  systems  are  installed  to 
independently  gather  data  without  influencing  or  affecting  the  bus  it  is  monitoriiig.  Also,  the 
limiting  factor  for  gathering  data  from  an  avionics  system  is  the  throughput  limit  of  the  data 
system  -  generally  the  recorder  or  the  transmitter  not  the  limitation  of  the  interface  method.  For 
example,  given  6  nodes  on  an  avionics  bus,  an  approach  that  limits  gathering  data  from  only  two 
nodes  at  one  time  is  not  considered  adequate. 

It  is  recognized  that  through  the  structured  approach  to  this  project,  a  new  paradigm  may  emerge. 
One  that  may  discount  or  even  disregard  some  of  the  tenets  provided  in  this  and  other 
documents. 

5  Concept  for  New  or  Modified  System 

5.1  Background,  Objectives,  and  Scope 

For  many  reasons  the  DoD  is  embracing  the  use  of  commercial  technology  in  many  of  today’s 
weapons  platforms.  This  makes  a  lot  of  sense  -  especially  in  the  area  of  communication 
standards.  The  large  numbers  of  computers  connected  to  the  Internet  has  brought  the  cost  of  10 
MB  Ethernet  boards  literally  to  a  few  dollars  apiece.  Custom  made  communication  boards  that 
run  at  the  same  speeds  can  cost  more  than  a  couple  of  thousand  dollars.  Articles  in  “Military  & 
Aerospace  Electronics”  and  “Electronic  Design”  have  listed  several  weapons  platforms 
upgrading  their  avionics  systems  with  Fibre  Channel.  Fibre  Channel  is  an  ANSI  standard 
operating  at  speeds  greater  than  1000  times  that  of  1553.  With  speeds  at  these  rates,  most 
designers  are  using  fiber  optic  cables  in  their  avionics  systems. 

The  objective  for  the  Fibre  Channel  Bus  Monitor  System  (FCBMS)  is  to  monitor  the  Fibre 
Channel  avionics  bus  for  data  of  interest  during  testing,  format  the  data,  and  send  it  on  to  the 
Test  and  Evaluation  (T&E)  data  system.  The  general  system  relationships  remain  as  they  were 
in  Figure  1.  The  only  difference  is  that  the  production  avionics  system  is  now  based  on  Fibre 
Channel  raflier  than  Mil-Std-1553.  However,  this  isn’t  as  trivial  as  it  might  sound.  The  speed, 
architecture,  and  fiber  optic  cabling  make  interfacing  to  the  bus  a  challenge. 

Fibre  Channel  systems  are  usually  designed  as  a  switched  fabric  as  shown  in  Figure  4.  The  data 
sent  from  one  node  passes  through  the  switch.  The  switch  looks  at  the  address  of  the  data  and 
forwards  the  data  to  the  correct  recipient.  Unlike  the  1553  bus,  only  the  recipient(s)  sees  the 
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data.  The  method  of  tapping  into  the  Fibre  Channel  avionics  bus  has  not  been  determined. 
Figure  4  therefore  shows  this  as  a  cloud  instead  of  a  specific  bus  tap.  The  scope  of  the  proposed 
system  remains  the  same  as  the  1553  bus  monitor  system.  It  will  consist  of  the  Fibre  Channel 
interface(s),  and  the  central  unit  where  the  data  is  formatted,  the  program  is  stored,  and  the  data 
system  interface  is  located.  . 


Figure  4  Fibre  Channel  Bus  Monitor  System  Context 


5.2  Operational  Policies  and  Constraints 

Although  there  are  always  exceptions,  in  general,  the  Fibre  Channel  bus  monitor  must  adhere  to 
the  following  constraints 

•  Must  adhere  to  the  Fibre  Channel  standards. 

•  Must  not  interfere  with  normal  operation  of  the  Fibre  Channel  bus. 

•  Must  not  introduce  additional  failure  modes 

5.3  Description  of  Current  System 

5.3.1  Operational  Environment 

The  system  operates  in  an  airborne  uninhabited  fighter  environment.  This  implies  a  rugged 
environment  with  tolerances  toward  higher  shock,  vibration,  temperature  extremes,  humidity, 
etc.  Its  use  on  test  vehicles  requires  a  small  volume  to  allow  installation  in  space  constrained 
environments. 


8 


5.3.2  Major  System  Components 

Since  this  is  a  proposed  system,  the  actual  configuration  is  expected  to  vary  based  on  any 
additional  requirements  levied  above  the  basic  monitoring  requirement.  The  general  physical 
configuration  is  expected  to  be  similar  to  the  existing  1553  bus  monitor  with  two  main 
components. 

•  Fibre  Channel  Interface(s).  A  test  article  is  expected  to  have  one  Fibre  Channel  avionics 
bus.  However,  since  the  method  of  interfacing  has  not  been  determined,  there  may  be  as  few 
as  one  and  as  many  as  the  number  of  nodes  in  the  avionics  system.  Depending  on  the  test, 
not  all  nodes  may  need  to  be  monitored. 

•  Central  Unit.  The  central  unit  performs  four  main  functions.  The  pre-programmed 
instructions  of  what  data  is  of  interest  is  stored  during  system  setup.  During  operation,  the 
bus  data  being  received  across  the  Fibre  Channel  interface  is  compared  to  the  instruction  set 
stored  in  memory.  The  data  that  is  of  interest  is  formatted  into  a  message  that  is  transmitted 
across  the  data  system  interface  to  the  data  system. 

-  Program  storage  -  Memory  to  which  the  user  uploads  operational  instructions. 

-  Data  comparator  -  Compares  incoming  data  messages  to  instructions  in  program  storage. 

-  Data  Message  Formatter.  -  Formats  selected  data  into  a  data  system  message  structure. 

-  Data  system  interface  -  Physical  interface  into  the  data  system. 

•  'Programming  Software.  This  software  may  be  a  standalone  program  or  a  part  of  the  overall 

data  system  software.  The  software  provides  an  interface  that  allows  the  user  to  select  the 
data  of  interest.  The  software  uploads  the  instructions  into  the  program  storage  memory  via 
the  data  system  interface. 

5.3.3  Interfaces  to  External  Systems  or  Procedures 

The  external  interfaces  are  not  expected  to  change  significantly  from  the  current  system  in 
theory.  However  in  practice,  the  two  major  external  interfaces  -  avionics  bus  interface  and  the 
data  system  interface  -  will  be  different.  The  avionics  bus  interface  will  be  Fibre  Channel 
instead  of  1553.  State-of-the-art  data  systems  are  upgrading  their  architectures  to  handle  data 
intensive  requirements  like  a  Fibre  Channel  Bus  Monitor.  As  a  result  the  data  system  will  most 
likely  be  something  different  than  is  currently  in  use. 

From  a  process  perspective,  the  instrumentation  engineer  will  need  to  research  the  data  available 
on  the  bus  and  uniquely  identify  that  data  to  the  data  system.  This  is  similar  to  procedures  in 
place  now  for  current  systems. 

The  new  system  will  still  need  to  be  programmed  before  it  is  useful  as  a  bus  monitor.  The 
logical  architecture  of  the  new  data  system  has  not  been  completely  defined  because  commercial 
network  standards  don’t  dictate  it.  The  logical  architecture  could  be  a  command/response  type 
like  current  systems  are  or  a  peer-to-peer  type  (reference  section  8.1.1  for  additional 
information).  In  a  peer-to-peer  case,  the  nodes  of  the  data  system  are  programmed  to  operate 
independently.  The  logical  architecture  of  the  data  system  will  have  an  effect  on  how  tightly 
coupled  the  bus  monitor  programming  software  is  to  the  rest  of  the  data  system. 

5.3.4  Capabilities/Functions  of  the  New  or  Modified  System 

The  function  of  the  proposed  system  is  to  watch  for  data  on  the  avionics  bus.  When  data  amves, 
it  is  checked  against  its  internal  programming.  Selected  data  is  sent  to  the  formatter  while 
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unwanted  data  is  discarded.  The  data  is  formatted  appropriately  and  sent  to  the  data  system 
interface  where  it  is  sent  to  the  appropriate  nodes  within  the  data  system.  - 

The  increased  data  available  on  a  Fibre  Channel  avionics  bus  as  well  as  increasing  data 
requirements  in  general  have  driven  data  systems  to  higher  bandwidth  data  bus.  Even  the  higher 
bandwidth  data  system  bus  would  be  swamped  in  a  heavily  loaded  Fibre  Channel  avionics 
system.  To  avoid  overloading  the  data  system  bus,  the  user  will  have  to  carefully  select  which 
data  is  of  interest. 

Fibre  Charmel  is  not  expected  to  totally  replace  1553  avionics  busses  in  the  near  term.  The  Fibre 
Channel  Bus  Monitor  will  operate  within  a  data  system  with  both  current  1553  and  Fibre 
Channel  avionics  bus  monitors  as  shown  in  Figure  5. 


5.4  Users  or  Involved  Personnel 

There  are  four  types  of  users  involved  with  operating  this  product.  In  some  organizations,  a 
single  individual  could  accomplish  more  than  one  function. 

□  Instrumentation  Engineer  -  This  person  understands  the  technical  details  of  the  capabilities 
of  this  system  and  how  they  relate  to  the  requirements  the  data  system  must  fulfill  overall. 
This  person  is  responsible  for  programming  the  system  to  obtain  the  desired  performance. 
This  person  is  also  involved  with  the  installation  of  the  FCBMS  insofar  as  where  it  will  be 
located  and  what  wiring  needs  to  be  run  to  support  it. 
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□  System  Installer  -  This  person  physically  installs  the  unit  into  the  test  article  in  the  location 
the  engineer  has  identified.  This  person  has  direct  knowledge  (or  a  support  structure)  of  how 
to  ensure  the  FCBMS  is  installed  in  a  safe  manner  relative  to  the.  vehicle  to-  which  it  is 
installed. 

□  Cable  Installer  -  This  person  physically  installs  the  wiring  as  identified  by  the  engineer. 
This  person  has  the  knowledge  of  how  to  properly  route  and  constrain  the  wire  runs 
throughout  a  given  test  vehicle.  This  person  may  need  a  working  knowledge  of  handling 
fiber  optic  cables,  e.g.  routing  and  splicing. 

□  Test  Operator  -  The  test  operator  is  the  person  actually  performing  the  test.  Dependent 
upon  the  type  of  test,  this  could  be  a  pilot,  driver,  or  lab  technician.  This  person  has  no 
detailed  knowledge  of  the  FCBMS  or  its  capabilities.  The  extent  of  operator  involvement  is 
limited  to  an  overall  data  system  power  switch. 

5.5  Support  Concept 

The  details  of  the  suppoK  concept  employed  by  each  organization  vary.  The  support  concept  is 
based  largely.on  how  they  are  funded,  the  number  of  systems  fielded  on  daily,  monthly  or  annual 
basis,  and  their  relationship  with  the  customer.  What  is  common  is  the  fact  that  FCBMS  are 
expected  to  be  commercial  , products.  Any  repairs  or  replacements  are  handled  directly  with  the 
factory.  This  implies  that  each  organization  have  some  contract  mechanism  available  to  reach 
that  particular  vendor. 

6  Operational  Scenarios 

6.1  Installation 


Users: 

Instrumentation  Engineer  (System  Layout/Design) 
System  Installer  (Hardware  mounting) 

Cable  Installer  (Electrical  connections) 

External 

Test  vehicle  (Physical) 

System 

Data  System  (Physical) 

Interfaces: 

Avionics  System  (Physical) 

Mode: 

Powered  Down  /  None 

Conceptually  the  FCBMS  will  consist  of  several  physical  pieces.  The  central  imit  (CU)  houses 
the  avionics  bus  tap  interface,  the  data  formatter  and  the  data  system  interface.  Dependent  upon 
the  avionics  design  and  the  data  required  to  monitor,  there  will  be  one  or  more  remote  bus  taps 
(RBT).  Installation  consists  oi. 

□  Mounting  the  FCBMS  in  the  test  article. 

□  Connecting  the  FCBMS  to  the  data  system  (both  data  and  power). 

□  Connecting  the  FCBMS  to  the  Avionics  system. 

During  unit  installation,  the  user  will  provide  the  FCBMS  (CU  plus  RBTs)  to  the  system 
installer.  The  system  installer  will  build  the  appropriate  brackets/hardware  to  hold  the  units 
firmly  in  the  test  vehicle  throughout  its  operating  environment.  Since  many  of  the  test  articles  are 
space  constrained,  there  is  usually  only  access  to  one  face  of  the  FCBMS  available.  Special 
mounting  hardware  may  be  required. 
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The  wiring  from  the  avionics  bus  tap  to  the  RBT  and  from  the  RBT  to  the  CU  will  be  routed 
through  the  test  artidle  by  the  cable  installer.  Appropriate  connectors  will  be  installed  connecting 
the  CU  and  RBT(s)V  The  cable  installer  will  connect  the  CU  to  the  data  system  by  routing  two 
cables  —  one  for  the  data  and  one  for  the  power. 

Most  likely  the  avionics  system  will  use  fiber  optic  cabling.  It  is  not  clear  at  this  time  whether 
the  ‘wiring’  used  in  the  FCBMS  will  be  copper  or  fiber  optic. 

6.2  System  Setup 


Users: 

Instrumentation  Engineer  (Functional  Design) 

External 

Data  System  (Electrical) 

System 

Interfaces: 

Ground  Support  System  (Logical) 

Mode: 

Program 

The  FCBMS  can  be  programmed  while  on  the  bench  or  while  installed  in  the  test  article.  The 
unirmust  be  programmed  prior  to  use.  The  ground  support  system  is  electrically  connected  to 
the  data  system.  It  is  therefore  logically  connected  to  the  FCBM.  Prior  to  actually  programming 
the  imit,  the  instrumentation  engineer  determines  what  data  on  the  avionics  bus  is  of  interest. 
This  determination  is  primarily  based  on  the  requirements  of  the  test  engineer(s).  Once  a  data 
list  is  created,  it  is  entered  into  the  ground  support  system.  Typical  items  to  be  entered  into  the 
support  system  include  bus  data,  message  format,  and  destination.  After  the  data  is  entered,  the 
support  system  loads  the  program  values  into  a  non-volatile  portion  of  memory  within  the 
FCBM. 

6.3  Data  Acquisition  during  Avionics  Bus  Validation 


Users: 

Test  Operator 

External 

Data  System  (Electrical) 

System 

Avionics  System  (Electrical) 

Interfaces: 

Test  vehicle  (Physical/Environmental) 

Mode: 

Acquisition 

Acquisition  mode  is  the  default  powered  up  state.  The  unit  is  designed  to  run  autonomously 
once  programmed.  The  users  in  this  scenario  typically  have  access  to  overall  data  system  power, 
data  recorder  start/stop  (if  there  is  one),  and  transmitter  on/off  (if  there  is  one).  When  operating, 
there  is  no  difference  in  operation  between  6.3  and  6.4.  The  difference  comes  in  how  they  are 
installed. 

When  validating  the  bus,  the  data  on  the  bus  is  compared  against  known  data  also  called  "truth 
data".  Truth  data  comes  from  other  systems  or  data  sources  (some  are  installed  specifically  for  a 
test)  with  known  accuracies  and  capabilities.  When  acquiring  the  data,  the  FCBMS  must  be 
transparent  to  the  avionics  system.  This  is  accomplished  during  the  installation  design  by 
carefiilly  choosing  interface  and  data  gathering  methods  that  do  not  affect  the  bus.  For  example, 
programming  the  avionics  software  to  send  additional  data  to  an  instrumentation  port  would 
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cause  the  system  react  differently  to  accommodate  the  data  system.  A  subsequent  avionics 
problem  might  be  attributable  to  the  increased  processing  or  additional  bandwidth  used  to 
acquire  the  data. 

The  FCBMS  monitors  the  data,  compares  the  data  against  the  programmed  instructions.  The 
program  tells  the  FCBMS  to  either  ignore  the  data  or  package  the  data  into  a  message  and 
forward  it  to  a  destination  in  the  data  system. 

6.4  Data  Acquisition  with  Avionics  Bus  as  Truth  Data  Source 


Users: 

Test  Operator 

External 

Data  System  (Electrical) 

System 

Avionics  System  (Electrical) 

Interfaces: 

Test  vehicle  (Physical/Environmental) 

Mode: 

Acquisition 

Acquisition  mode  is  the  default  powered  up  state.  The  unit  is  designed  to  run  autonomously 
once  programmed.  The  users  in  this  scenario  typically  have  access  to  overall  data  system  power, 
data  recorder  start/stop  (if  there  is  one),  and  transmitter  on/off  (if  there  is  one).  When  operating, 
there  is  no  difference  in  operation  between  6.3  and  6.4.  The  difference  comes  in  how  they  are 
installed. 

Once  the  bus  has  been  validated  and  the  test  engineer  is  comfortable  with  the  quality  of  data  on 
the  bus,  other  methods  of  interfacing  to  the  avionics  bus  become  acceptable.  The  method  used 
when  validating  the  bus  is  acceptable  by  definition.  That  method  may  be  costly  or  limited  in 
capability.  As  a  result,  there  may  be  other  methods  that  may  become  acceptable  now  that  the  bus 
has  been  validated.  These  methods  allow  the  production  system  to  know  that  an  instrumentation 
data  system  is  present  and  react  accordingly.  The  actual  method(s)  employed  will  be  discussed 
in  future  documents. 

The  FCBMS  monitors  the  data,  compares  the  data  against  the  programmed  instructions.  The 
program  tells  the  FCBMS  to  either  ignore  the  data  or  package  the  data  into  a  message  and 
forward  it  to  a  destination  in  the  data  system. 

7  Summary  of  Impacts 

7.1  Operational  Impacts 

This  system  is  in  response  to  the  need  to  move  more  data  aroimd  the  weapons  platform.  During 
testing,  the  additional  data  will  need  to  be  monitored  to  ensure  the  validity  of  the  source  or  to 
identify  what  is  happening  on-board.  The  impact  of  this  additional  data  will  show  up  in  several 
ways.  The  knowledge  of  ever  increasing  data  requirements  has  led  the  T&E  commtmity  to  find  a 
higher  bandwidth  data  bus  to  move  more  data  between  data  system  components.  However,  just 
moving  more  data  is  not  enough.  There  must  be  sinks  for  the  data.  Data  sinks  include  displays, 
recorders,  and  transmitters.  Higher  bandwidth  recorders  and  transmitters  will  impact  the  data 
reduction  facility.  Both  will  affect  the  amount  of  data  that  needs  to  be  processed  for  the  test 
engineer.  The  recorder  also  means  more  data  to  archive. 
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The  Fibre  Channel  avionics  bus  interface  method  has  yet  to  be  determined.  There  is  significant 
potential  for  the  interface  method  to  change  the  way  T&E  requirements  are  viewed  by  the 
avionics  designers.  One  poncept  is  to  program  the  avionics  system  with  the  T&E  data  needed 
and  send  the  data  to  a  known  T&E  address. 

7.2  Organizational  Impacts 

□  The  use  of  fiber  optics  will  require  the  T&E  organizations  to  become  familiar  with  handling, 
routing  and  splicing  optical  cables. 

□  Personnel  will  need  to  be  knowledgeable  of  Fibre  Channel  and  appropriate  network 
protocols. 

□  Test  equipment  to  support  Fibre  Channel  protocols  and  rates  will  be  required. 

□  Since  Fibre  Channel  is  a  commercial  network  standard,  the  vendors  may  be  different  than  we 
are  used  to  dealing.  New  contracts  vehicles  may  be  required. 

7.3  Impacts  During  Development 

The  T&E  organizations  will  need  a  small  team  of  people  that  understand  Fibre  Channel,  the 
implications  of  various  interface  methods,  and  how  the  various  methods  will  affect  T&E 
operations.  Most  importantly  is  whether  a  particular  interface  or  method  of  data  collection  will 
add  any  significant  failure  modes  to  the  test  vehicle. 

Both  the  management  and  the  team  must  be  open  to  what  may  currently  be  considered 
unconventional  approaches  to  meeting  the  need  of  collecting  bus  data. 
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8  Notes 

8.1  Fibre  Channel  Introduction 

Fibre  Channel  is  the  general  name  of  an  integrated  set  of  standards  being  developed  by  the 
American  National  Standards  Institute  (ANSI)  which  defines  new  protocols  for  flexible 
information  transfer.  Fibre  Channel  development  began  in  1988  as  an  extension  of  work  on  the 
Intelligent  Peripheral  Interface  (IPI)  Enhanced  Physical  standard,  and  branched  out  in  several 
directions.  Fibre  Channel  is  a  serial  protocol  that  is  unaware  of  the  content  or  meaning  of  the 
information  being  transferred.^ 

8.1.1  Architecture 

Fibre  Channel  by  itself  does  not  imply  the  type  of  architecture  an  instrumentation  system  must 
utilize.  There  are  two  basic  architectures  that  can  be  employed  in  the  design  of  the  system.  The 
nodes  may  or  may  not  support  both  architectures.  In  the  traditional  system,  a  controller  or 
master  is  used  to  command  the  nodes  and  receive  the  responses.  The  controller  is  programmed 
with  the  knowledge  of  the  overall  format  and  directs  each  node  to  acquire  data  and  respond 
(reference  Figure  6).  The  controller  typically  becomes  the  aggregator  of  the  data  as  it  formats 
the^utput(s)  for  recording,  transmitting,  or  processing.  This  keeps  the  nodes  simple.  Traffic  on 


Figure  6  Controller  Based  Architecture 

the  bus  is  very  orderly  based  on  what  the  controller  requests.  This  is  known  as  a  command- 
response  architecture.  Multiple  formats  can  be  stored  in  the  controller  and  changed  via  an 
external  switch  or  sophisticated  uplink.  Controllers  can  vary  from  small,  inexpensive  units  that 
are  inflexible  to  large  expensive  units  that  can  do  everything. 


*  “What  is  Fibre  Channel?”,  fourth  edition,  Ancot  Corporation 
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Another  architecture  available  to  the  instrumentation  network  is  the  peer-to-peer  architecture. 
Each  node  is  programmed  with  its  own  schedule.  Individually  the  nodes  determine  when  to 
acquire  the  data,  how  to  packetize  the  data,  whom  to  send  it  to,  and  how  often  to  send  it 
(reference  Figure  7).  One  of  the  advantages  of  an  autonomous  system  is  the  ease  of  adding  new 
nodes.  Additional  nodes  just  need  to  be  physically  connected  to  the  bus  and  programmed.  The 
other  nodes  are  not  affected  (assuming  plenty  of  bandwidth  on  the  bus).  One  node  could  still 
receive  all  the  data  and  format  it  into  the  proper  outputs  for  recording  and  transmitting  similar  to 
the  command  response  architecture. _ 


Figure  7  Peer-to-Peer  Architecture 


8.1.2  Topology 

Fibre  Chartnel  defines  three  major  topologies  -  point-to-point,  fabric,  and  arbitrated  loop.  The 
point-to-point  topology  is  the  simplest.  It  connects  two  ports  with  a  bi-directional  link  consisting 
of  a  transmit  cable  and  a  receive  cable  (reference  Figure  8). 


In  the  Fabric  topology,  each  node  is  connected  to  a  switch.  Depending  on  the  capabilities  of  the 
switch,  any  node  may  connect  to  any  other  node  (reference  Figure  9).  When  denoting  Fabric 
topologies,  the  Fabric  is  shown  as  a  cloud.  This  represents  the  Fabric  notion  without  showing 
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any  physical  connections.  One  of  the  drawbacks  of  Fabric,  is  the  requirement  for  one  or  more 
Fabric  switches  that  physically  take  the  place  of  the  network  cloud.  These  are  not  necessarily 
cheap  -  especially  for  a  test  environment.  Because  of  the  connectivity,  adding  additional  nodes 
increases  the  total  bandwidth  available  to  the  system.  In  reality,  this  is  only  true  if  there  is  a 
broad  distribution  of  network  traffic.  If  all  nodes  are  trying  to  talk  through  one  link  to  the 
recorder,  then  more  nodes  will  only  make  it  worse. 


The  arbitrated  loop  topology  is  a  simple  concatenation  from  the  transmitter  of  one  node  to  the 
receiver  of  the  next.  This  progresses  through  all  nodes  until  the  last  transmitter  is  connected  to 
the  first  receiver  to  form  a  loop  (reference  Figure  10).  Simplicity  is  one  of  the  advantages  of  a 
loop.  There  is  no  additional  network  hardware  required  for  connectivity.  To  add  more  nodes, 
the  loop  is  broken  with  the  additional  nodes  being  inserted  between  the  break.  One  of  the 
drawbacks  of  a  loop  is  the  constant  bandwidth.  Regardless  of  the  number  of  nodes,  they  all 
share  the  same  bandwidth. 


The  last  type  of  topolbgy  available  is  the  hybrid  topology.  The  hybrid  topology  simply  replaces 
one  of  the  fabric  nodes  with  a  loop.  Conversely,  it  replaces  a  loop  node  with  a  fabric  (reference 
Figure  1 1).  This  is  one  instance  of  a  hybrid  topology,  of  which  there  are  many  variations.  This 
topology  has  the  pros  and  cons  of  both  reference  Table  1 ; 


Table  1,  Topology  Characteristics 


Scaleable  Bandwidth 
Unlimited  Nodes 
More  Fault  Tolerant 


Simple  to  Implement 

Cheaper  (No  additional  components) 


Complex  to  Implement 

More  Expensive  (Requires  Switch) 


Constant  Bandwidth 

126  nodes  maximum  per  loop 

1  fault  disrupts  the  loop _ 


8.2  Acronyms  &  Abbreviations 

1553  Mil-Std-1553 

BC  Bus  Controller 

BMS  Bus  Monitor  System 

CAIS  Common  Airborne  Instrumentation  System 

CU  Central  Unit 

DSC  Data  System  Controller 

FCBMS  Fibre  Channel  Bus  Monitor  System 

RBT  Remote  Bus  Tap 

RT  Remote  Terminal 

T&E  ,  Test  and  Evaluation 


18 


8.3  Fibre  Channel  Reference  Material 

>  “Fibre  Channel:  Connection  to  the  Future”,  The  Fibre  Channel  Association,  1995 

>  “What  is  Fibre. Channel?”,  Fourth  Edition,  Ancot  Corporation,  1997- 

>  “Fibre  Channel:  The  Basics”,  Stephens,  Gary  R.  and  Jan  V.  Dedek,  1 997 

>  “The  Fibre  Channel  CftOSultant:  A  Comprehensive  Introduction”,  Kembel,  Robert  W., 
1998 

>  “Fibre  Channel:  Gigabit  Communications  and  I/O  for  Computer  Networks”,  Benner, 
Alan  F.,  1996 
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1  Scope 

The  goal  of  this  document  is  to  describe  the  external  interfaces  as  seen  by  a  Fibre  Charmel 
Avionics  Bus  Monitor.  This  will  be  accomplished  by  identifying  all  external  interfaces  and 
describing  their  requirements. 

2  System  External  Interface  Requirements 

2.1  Interface  Identification  and  Diagrams 

There  are  three  external  interfaces  for  the  Fibre  Channel  Avionics  Bus  Monitor  System  -  The 
Fibre  Channel  (FC)  Avionics  Bus,  The  Test  and  Evaluation  (T&E)  Data  System  Bus,  and  T&E 
Data  System  Power.  Table  1  identifies  these  interfaces  along  with  their  associated  project 
unique  identifier  (PUID),  interfacing  entities,  and  interface  characteristics.  Characteristics 
identified  as  ‘primary’  impose  their  requirements  on  other  interfacing  entities.  Conversely, 
interfaces  identified  as  ‘secondary’  have  requirements  imposed  on  them  by  the  interfacing  entity. 
The  interfaces  are  shown  graphically  in  Figure  3  and  will  be  discussed  in  the  succeeding 
sections. 


Table  1  External  Interfaces 


■  .Name--  ■ 

PUID 

Charniitjelididis 

FC  Avionics  Bus  I/F 

XIF-FC 

Production  Avionics  Bus 

Secondary,  Input 

T&E  Data  System  Bus  I/F 

XIF-DATA 

COTS  Data  System  Bus 

Secondary,  Bi-directional 

T&E  Data  System  Power  1/F 

XIF-PWR 

Data  System  Power  Distribution 

Figure  3  External  System  Interfaces 
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2.2  Fibre  Channel  Avionics  Bus  I/F  (XIF-FC) 

2.2.1  Purpose  ^  . 

This  interface  provides  avionics  data  transfer  from  the  production  aAdonics  bus  to  the  bus 
monitor.  •  ‘ 


2.2.2  Description 

Messages  from  the  Fibre  Channel  Avionics  Bus  will  traverse  this  interface.  This  message  will  be 
encapsulated  using  transport,  network,  and  data  link  protocols  decided  upon  by  the  avionics 
designer  as  shown  in  Table  2.  The  Fibre  Channel  interface  will  have  to  adhere  to  the  same  Fibre 
Channel  standards  used  by  the  avionics  system.  At  the  top  level,  the  standards  would  be  the 
ANSI  standards  as  listed  in  section  2.2.10.  These  standards  are  expected  to  be  modified  by  the 
ANSI  Fibre  Channel  Avionics  Environment  Technical  Report.  A  manufacturer  or  platform 
specific  report  may  further  modify  the  Fibre  Channel  standard  used  by  the  avionics.  The 
implication  to  this  interface  is  that  it  must  be  programmable  to  accommodate  these  potential 
differences.  Layered  on  top  of  the  Fibre  Channel  are  the  network  and  transport  protocols. 
Again,  these  may  be  different  for  various  manufacturers  and  platforms.  As  these  issues  are 
identified,  this  document  will  be  updated. 

Table  2  XIF-FC  Layered  Model 


OSI  Layer 


Application 


Presentation 


Session 


Transport 


Network 


Data  Link 


Physical 


Standard  Standard  Body 


2.2.3  Priority 

The  system  shall  assign  a  high  priority  to  this  interface.  All  data  of  interest  must  be  captured. 


2.2.4  Type 

This  shall  be  a  real-time  interface. 


2.2.5  Characteristics  of  Incoming  Data  Elements 


Name 

FC  Avionics  Bus  Data 

PUID 

DI-FC 

Source 

Production  FC  Avionics  Bus 

Units 

Not  Applicable 

Data  Type 

Payload 

Range 

Not  Applicable 

Size/Format 

As  defined  in  section  2.2.10 

Accuracy 

Not  Applicable 
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2.2.6  Characteristics  of  Outgoing  Data  Elements 

There  shall  be  no  outbound  communication  through  XIF-FC. 


2.2.7  Characteristics  of  Communications  Methods 

The  communications  methods  that  shall  be  used  are  defined  by  the  reference  documents  in 
section  2.2.10 

2.2.8  Characteristics  of  Protocols 

The  protocols  that  shall  be  used  are  defined  by  the  reference  documents  in  section  2.2.10 

2.2.9  Relationship  to  System  Modes 

The  following  table  shows  the  relationship  of  the  Fibre  Channel  Avionics  Interface  to  the  modes 
of  the  system. 

Taole  3  XIF-FC  Relationship  to  System  Modes 

Mode:  OFF 

When  the  system  is  in  the  ‘OFF’  state,  i.e.  powered  down,  there  is  no  activity  on  the 
-  interface.  The  interface  method  shall  not  interfere  with  normal  avionics  operation  when 
the  bus  monitor  is  powered  off. 

Mode:  OPERATIONAL 

During  OPERATIONAL  mode,  the  interface  is  active.  Data  appearing  on  the  avionics 
bus  is  sent  across  the  interface  where  the  system  decides  to  send  it  forward  or  throw  it 
away. 

Mode:  PROGRAM 

During  PROGRAM  mode,  the  interface  is  not  active.  The  interface  method  shall  not 
interfere  with  normal  avionics  operation  when  the  bus  monitor  is  in  PROGRAM  mode. 

Mode:  DIAGNOSTIC 

During  DIAGNOSTIC  mode,  the  interface  is  not  active.  The  interface  method  shall  not 
interfere  with  normal  avionics  operation  when  the  bus  monitor  is  in  DIAGNOSTIC 
mode. 


2.2. 1 0  XIF-FC  Reference  Documents 


ANSI  X3 .230- 1994 

ANSI  X3. 297- 1997 

ANSI  X3.303-1998 

ANSI  X3.nnn-200x* 
ANSI  X3.nnn-200x* 


Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  (FC-PH),  1 994 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  2  (FC-PH-2),  1997 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  3  (FC-PH-3),  1998 

Information  Technology  -  Fibre  Channel  -  Physical  Interfaces  (FC-PI) 
Information  Technology  -  Fibre  Channel  -  Framing  and  Signaling 
(FC-FS) 


*  FC-Pl  and  FC-FS  are  currently  in  work  and  will  supercede  FC-PH,  FC-PH-2,  and  FC-PH-3 
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ANSI  X3.nnn-200x 


Information  Technology  -  Fibre  Channel  —  Virtual  Interface 
Architecture  Mapping  Protocol  (FC-VI) 

ANSI  X3.nnn-200x  Fibre  Channel  Avionics  Environment  Technical  Report  (due  12/00) 
Boeing-STL  99A0098  F/A-1 8  Fibre  Channel  Network  Interface  Control  Document,  Rev  -  ,25 

August,  2000  (Dist  D  -  Limited  to  DoD  and  DoD  Contractors  Only) 

2.3  T&E  Data  System  Bus  (XIF-DATA) 

2.3.]  Purpose 

This  interface  outputs  formatted  avionics  bus  message  data  transfer  from  the  bus  monitor  system 
to  the  T&E  Data  System  as  well  as  receives  system  programming  information. 

2.3.2  Description 

In  the  near  future,  the  T&E  Data  System  Bus  is  expected  to  migrate  to  a  Fibre  Channel  based 
system  as  defined  in  the  ANSI  Fibre  Channel  Standards  and  modified  by  the  TRIG  (Interrange 
Instrumentation  Group)  Telemetry  Standards  Part  II.  The  interface  will  reside  in  the  bus  monitor 
and  be  perceived  by  the  data  system  as  another  node. 


Table  4  XIF-DATA  Layered  Model 

OSI  Layer  Standard  Standard  Body 


2.3.3  Priority 

The  system  shall  assign  a  medium  priority  to  this  interface. 

2.3.4  Type 

This  shall  be  a  real-time  interface. 


2.3.5  Characteristics  of  Incoming  Data  Elements 


Name 

System  Programming  Data 

PUID 

Dl-SPD 

Source 

T&E  Data  System  Support  Unit 

Units 

Not  Applicable 

Data  Type 

Payload 

Range 

Not  Applicable 

Size/Format 

TBD 

Accuracy 

Not  Applicable 
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2.3.6  Characteristics  of  Outgoing  Data  Elements 


Name 

T&E  Formatted  Avionics  Data 

PUID 

DO-FAD 

Source 

Internal  •  ^ 

Units 

Not  Applicable 

Data  Type 

Payload 

Range 

Not  Applicable 

Size/Format 

As  defined  in  section  2:5.10 

Accuracy 

Not  Applicable 

2.3.7  Characteristics  of  Communications  Methods 

The  communications  methods  that  shall  be  used  are  defined  by  the  reference  documents  in 
section  2.3.10 

2.3.8  Characteristics  of  Protocols 

The  protocols  that  shall  be  used  are  defined  by  the  reference  documents  in  section  2.3.10 

2.3.9  Relationship  to  System  Modes 

The  following  table  shows  the  relationship  of  the  T&E  Data  System  Interface  to  the  modes  of  the 
system. 

Table  5  XIF-DATA  Relationship  to  System  Modes 

Mode:  OFF 

When  the  system  is  in  the  ‘OFF’  state,  i.e.  powered  down,  there  is  no  activity  on  the 
interface. 

Mode:  OPERATIONAL 

During  OPERATIONAL  mode,  the  interface  is  active.  Avionics  data  is  formatted  and 
given  a  destination  address  within  the  T&E  data  system.  The  data  flow  across  the 
interface  is  primarily  from  the  bus  to  the  T&E  system  in  the  form  of  avionics  data.  There 
may  be  some  command  activity  being  received  by  the  interface  from  the  T&E  system. 

Mode:  PROGRAM 

During  PROGRAM  mode,  the  interface  is  receiving  data  from  the  T&E  system  and  stores 
the  data  in  non-volatile  program  memory.  Data  being  transmitted  across  the  interface 
will  be  limited  to  program  acknowledgement  type  of  data. 

Mode:  DIAGNOSTIC 

During  DIAGNOSTIC  mode,  the  interface  is  transmitting  internal  diagnostic  data  from 
throughout  the  bus  monitor  to  the  T&E  Data  System.  There  may  be  some  command 
_ activity  being  received  by  the  interface  from  the  T&E  system _ 


2.3.10  XIF-DATA  Reference  Documents 


IRIG  Standard  1 06-xx 

RFC-768 

RFC-2625 

ANSI  X3. 230- 1994 

ANSI  X3.297-1997 


Telemetry  Standards,  DRAFT  of  Fibre  Channel  implementation  for 
data  systems.  Due  to  be  released  Jan,  2001 
User  Datagram  Protocol  (UDP),  28-Aug-80 
IP  and  ARP  over  Fibre  Channel,  June  1999 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  (FC-PH),  1994 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  2  (FC-PH-2),  1997 
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ANSI  X3.303-1998 

ANSI  X3.niin-200x 
ANSI  X3.nnn-200x* 
ANSI  X3.nnn-200x* 


Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  3  (FC-PH-3),  1998 

Fibre  Channel  Avionics  Environment  Technical-Report  (due  12/00) 
Information  Technology  -  Fibre  Channel  -  Physical  Interfaces  (FC-PI) 
Information  Technology  -  Fibre  Channel  -  Framing  and  Signaling 
(FC-FS) 


2.4  T&E  Data  System  Power  (XIF-PWR) 

2.4.1  Purpose 

This  interface  provides  the  power  needed  to  run  the  Fibre  Channel  Avionics  Bus  Monitor. 

2.4.2  Description 

The  T&E  Data  System  will  provide  the  power  required  to  run  the  Fibre  Channel  Avionics  Bus 
Monitor.  The  T&E  data  system  shall  distribute  raw  aircraft  power  or  regulated  power.  This 
allows  a  master  switch  to  shut  down  the  entire  data  system. 


2.4.3  Priority 

The  system  shall  assign  a  moderate  priority  to  this  interface. 

2.4.4  Type 

This  is  a  non-data  interface. 


2.4.5  Characteristics  of  Incoming  Elements 


Name 

T&E  Data  System  Power 

PUID 

DI-PWR 

Source 

Production  FC  Avionics  Bus 

Units 

Volts 

Data  Type 
Size/Format 

Power 

Range 

22.0  to  29.0  steady  state 

Not  Applicable 

Ripple 

1 .5  max 

Governing 

Standard 

28Volts  as  defined  in  Mil-Std-704E 

Transient 

Transient  response  as  defined  in  Mil-Std- 
704 A  (fig  9  curves  1&4  and  fig  17) 

2.4.6  Characteristics  of  Outgoing  Elements 

There  shall  be  no  outbound  elements  through  XIF-PWR. 


2.4.7  Characteristics  of  Communications  Methods 
Not  Applicable 

2.4.8  Characteristics  of  Protocols 
Not  Applicable 

2.4.9  Relationship  to  System  Modes 

The  following  table  shows  the  relationship  of  the  T&E  Data  System  Power  Interface  to  the 
modes  of  the  system. 


*  FC-PI  and  FC-FS  are  currently  in  work  and  will  supercede  FC-PH,  FC-PFI-2,  and  FC-PH-3 
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Table  6  XIF-PWR  Relationship  to  System  Modes 


Mode:  OFF 

When  the  system  is  in  the  ‘OFF’  state,  i.e.  powered  down,  there  is  no  activity  on  the 
interface. 

Mode:  OPERATIONAL 

During  OPERATIONAL  mode,  the  interface  is  active.  28  VDC  is  supplied  to  the  Bus 
Monitor. 

Mode:  PROGRAM 

During  PROGRAM  mode,  the  interface  is  active.  28  VDC  is  supplied  to  the  Bus 
Monitor. 

Mode:  DIAGNOSTIC 

During  DIAGNOSTIC  mode,  the  interface  is  active.  28  VDC  is  supplied  to  the  Bus 
Monitor. 


2.4.10  Reference  Documents 

Mil-Std-704A  Aircraft  Electric  Power  Characteristics* 

Mil-Std-704E  Aircraft  Electric  Power  Characteristics,  l-May-91 

2.5  Summary  of  Data  Elements 


T able  7  Summary  of  Data  Elements 


mmnm 

XIF-FC 

Fibre  Channel  Avionics  Bus  Interface 

Dl-FC 

XIF-DATA 

T&E  Data  Systems  Bus 

DI-SPD 

DO-FAD 

T&E  Formatted  Avionics  Data 

XIF-PWR 

T&E  Data  System  Power 

Dl-PWR 

Bus  Monitor  Power 

XI F-  External  Interface 

D  ~  Data  Element;  I  -  Input;  O  -  Output 

*  Document  is  no  longer  available.  Transient  characteristics  are  supplied  in  the  appendix  for  completeness. 
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Appendix:  Mil-Std-704A  Transient  Characteristics 

M1I^STD-70W 
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FIGURE  9#  Transient  surge  dc  voltaga  8t<p  ftftcti6n  :lodt  lialts 
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1  Scope 

This  System  Requirements  Document  identifies  the  top-level  operational  and  pkformance 
requirements  for  the  Fibre  Channel  Avionics  Bus  Monitor.  The  documents  listed  in  section  two 
are  considered  part  of  this  document  by  reference. 

2  Documents 

2.1  Project  Documents 

Statement  of  Need,  30-0ct-00 
Operational  Concept  Document,  30-0ct-00 
External  Interface  Requirements,  26-Nov-OO 

2.2  Referenced  Documents 

IRIG  106,  Range  Comma..ders  Council  Telemetry  Standards,  2000 
Mil-Std-704A,  Aircraft  Electric  Power  Characteristics,  09-AUG-1966 
Mil-Std-704E,  Aircraft  Electric  Power  Characteristics,  01 -MAY- 1991 

Mil-Std-461E,  Requirements  For  The  Control  Of  Electromagnetic  Interference  Characteristics 
Of  Subsystems  And  Equipment,  20-AUG-l  999 

Mil-Std-8 1  OF,  Environmental  Engineering  Considerations  And  Laboratory  Tests,  Ol-NOV-2000 

3  System  Description 

The  Fibre  Channel  Avionics  Bus  Monitor  is  used  to  monitor  Fibre  Channel  avionics  busses 
located  on  weapons  platforms  for  test  and  evaluation  (T&E)  purposes  -  primarily  during 
developmental  testing. 

A  T&E  Data  System  acquires  data  during  a  test  or  mission.  This  data  is  recorded  for  post-flight 
analysis.  The  data  may  also  be  transmitted  to  a  ground  processing  facility  for  in-flight  data 
monitoring.  As  such,  the  T&E  data  system  must  be  invisible  to  the  operation  and  control  of  the 
aircraft.  The  T&E  data  system  typically  consists  of  independent  wiring,  data  acquisition  units, 
and  .  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed  and  the  aircraft  is 
returned  to  fleet  status.  The  data  system  may  also  be  known  as  an  instrumentation  system  or  a 
telemetry  system. 

As  can  be  seen  by  the  red  dashed  box  in  Figure  1 ,  a  bridging  system  is  needed  to  gather  the  data 
of  interest  from  the  production  avionics  system  and  format  the  data  into  something  useful  for  the 
T&E  data  system.  The  bus  monitor  conceptually  consists  of  two  parts.  The  first  part  is  the 
actual  interface  to  the  production  avionics  system  identified  as  a  bus  tap.  The  second  part  is  the 
unit  that  receives,  formats,  and  outputs  the  data. 

A  block  diagram  of  the  Fibre  Channel  Bus  Monitor  unit  is  shown  in  Figure  2.  The  Fibre 
Channel  interface  receives  avionics  data  from  the  bus  tap  in  the  Fibre  Channel  Avionics 
Network.  The  avionics  message  is  time  tagged  via  a  time  circuit  that  was  synchronized  from  the 
T&E  Data  System.  The  comparator  looks  at  the  program  memory  for  avionics  messages  of 
interest.  If  the  message  in  the  buffer  was  requested,  it  passes  the  message  to  the  Output  Message 
Formatter.  The  Formatter  creates  an  output  message  based  on  whether  the  operational  mode  is 
Truth’  or  ‘Validate’.  Once  complete,  the  output  message  is  sent  to  the  Data  Interface  where  it 
enters  the  T&E  Data  Network.  When  in  the  program  state,  T&E  support  unit  talks  to  the 
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Program  Control  through  the  Data  Interface.  The  Program  Control  can  read,  load,  verify,  and 
clear  the  non-volatile  program  memory.  The  Diagnostic  Control  receives  status  data  from  all 
subsystems.  When  in  the  operational  state,  a  subset  of  the  status  words  are  available  as  status 
messages  to  the  data  system.  When  in  the  diagnostic  state,  a  more  thorough  test  is  done  which 
would  interrupt  the  data  collection  during  normal  operations.  The  power  for  the  unit  is  received 
from  the  T&E  Data  System. 


Figure  1  System  Relationships 


Figure  2  Block  Diagram 
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4  Requirements 

4.1  Required  States  and  Modes 

The  unit  shall  have  the  following  states  as  a  minimum.  Additional  states  or  modes  are  allowe 


4.1.1  OFF 

This  state  is  characterized  as  having  no  power  applied  to  the  power  input  interface.  There  is  no 
difference  made  to  whether  the  unit  is  sitting  on  a  storage  shelf  or  wired  in  an  operational 

configuration. 


4.1.2  OPERATIONAL  ,  .  .  ^  ^ 

This  is  the  normal  state  of  the  unit.  During  this  state,  data  from  the  Avionics  Bus  Momtor 
Interface  (XIF-FC)  is  formatted  based  on  internal  program  requirements  for  dissemination  across 

the  T&E  Bus  Interface  (XIF-DATA). 


4J.2.1  Validate  Mode  .  .  r-  n 

This  mode  is  used  when  the  quality  of  the  production  avionics  data  is  suspect.  Generally 

when  using  this  mode,  one  or  more  of  the  avionics  sub-systems  are  under  test.  TLe  actual 
data  values  being  sent  are  only  half  the  story.  Other  equally  important  questions  include:  the 
state  of  the  bus,  which  node  sent  the  data  and  when,  and  which  nodes  received  the  data  and 

when. 


4.1.2.2  Truth  Mode  .  .  , 

This  mode  is  used  when  the  production  avionics  data  is  known  to  be  good.  The  avionics  data 

was  previously  validated  and  is  now  considered  the  truth  source  in  validating  other  systems. 
During  this  mode,  only  the  data  is  of  concern  -  not  the  state  of  the  bus. 


When  in  the  program  state,  the  unit  is  receiving  instructions  across  the  T&E  Bus  Interface  (XIF- 
DATA)  and  storing  them  in  non-volatile  memory  for  execution  during  the  Operational  state. 


4.1.4  DIAGNOSTIC 

The  diagnostic  state  allows  the  user  access  to 
interface. 


all  areas  of  memory  through  the  XIF-DATA 


4.2  System  Capability  Requirements 

4.2.1  Fibre  Channel  Avionics  Bus 

4.2.L1  Interference  with  normal  avionics  operation 

Regardless  of  the  state  of  the  unit,  operation  of  the  avionics  bus  shall  not  be  compromised. 

4.2.1.2  Avionics  Compatibility  .  .  ^ 

The  Fibre  Channel  standard  does  not  guarantee  interoperability.  Given  the  absence  of  a  Fibre 
Channel  Avionics  standard,  it  is  envisioned  that  manufacturers  of  different  platforms  may 
design  their  Fibre  Channel  avionics  network  differently.  This  unit  shall  be  configurab  e  to 
accommodate  multiple  Fibre  Channel  avionics  approaches.  Configurability  may  include,  but 
is  not  limited  to,  a  modular  approach  where  the  interface  board  is  swapped  out. 

4.2.1.3  Number  of  Avionics  Interfaces  ,  ^  j.v  >  a 

The  amount  of  data  that  can  be  monitored  is  limited  by  the  output  bandwidth  of  the  unit.  A 
single  Fibre  Channel  interface  may  consume  the  entire  output  bandwidth  available.  Howler, 
due  to  the  point-to-point  nature  of  Fibre  Channel  communications,  data  may  be  required  from 
multiple  nodes.  In  a  system  with  two  mission  computers  connected  to  redundent  switches,  t  e 


4 


minimum  requirement  will  be  to  monitor  both  receive  lines  from  both  switches  to  each 
mission  computer  or  four  interfaces.  The  unit  shall  accommodate -1  to  n  avionics  input 
interfaces,  where  n  >  4. 

4. 2. 1.4  Number  of  Bus  Messages 

Fibre  Channel  avionics  systems  are  only  now  being  developed.  In  the  absence  of  hard 
numbers  for  the  quantity  of  bus  messages  available,  the  number  of  Mil-Std-1553  messages 
(2'^)  will  be  used  as  a  starting  point.  The  unit  shall  be  programmable  to  select  up  to  65536 
individual  messages. 

4.2.2  T«&E  Data  System 

4. 2.2.1  T&E  Data  System  Compatibility 

The  current  DoD  data  system  standard  is  the  Common  Airborne  Instrumentation  System 
(CAIS).  To  meet  future  requirements,  the  Range  Commanders  Council  (RCC)  has  identified 
Fibre  Channel  as  the  basis  for  the  next  generation  data  system.  The  T&E  data  system 
interface  shall  be  CAIS  or  Fibre  Channel  as  defined  in  IRIG  106. 
Note:  Good  design  and  marketing  practices  would  allow  for  a  modular  interface  that  could  be  swapped  out  for 
either  interface  desired. 

4'.2.2.2  Validate  Mode  Data  Format 

Validate  mode  is  used  when  the  bus  data  is  being  tested  and  therefore  not  a  source  of  truth 
data.  When  in  Validate  mode,  other  information  besides  the  data  shall  be  captured.  It  is 
expected  that  all  messages  will  be  transferred  within  a  single  Fibre  Channel  frame.  The  entire 
Fibre  Channel  frame  shall  be  time  tagged  and  encapsulated  as  the  data  payload  (less  the  start 
and  end  of  frame  identifiers)  An  example  is  shown  in  Figure  3  (A). 

4. 2.2.3  Truth  Mode  Data  Format 

Truth  mode  is  used  when  the  bus  data  is  being  used  as  a  truth  source.  The  data  is  believed  to 
be  accurate.  When  in  Truth  mode,  only  the  time  tag  and  message  data  shall  be  sent  across  the 
T&E  interface.  An  example  is  shown  in  Figure  3  (B) 


Figure  3  Example  Capture  Data  Format,  (A)  Validate  Mode  (B)  Truth  Mode 
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4.2.2.4  Time  Tagging 

Time  correlation  of  acquired  avionics  bus  data  is  accomplished  by  internal  time  counters  and 
time  tagging  circuits,  which  are  synchronized  to  the  network  time  broadcast  across  the  T&E 
data  system.  Accuracy  of  the  time  tag  shall  be  1 .0  microseconds  or  better.  The  resolution  of 
the  time  tag  shall  be  0.10  microseconds  or  better.  The  time  format  shall  be  in  accordance  with 
IRIG  106. 

4.2.2.5  Power 

The  unit  shall  operate  from  Mil-Std-704E  28VDC  power  with  transient  charactenstics  m 
accordance  with  figure  9  (curves  1&4)  and  figure  17  from  Mil-Std-704A. 

4.2.3  Logistics 

4.2.3.1  Programming  ports 

Programmability  of  the  unit  shall  be  done  through  the  T&E  Data  System  Bus  (XIF-DATA) 
Interface.  Additional  program  ports  such  as  RS-232  and  Ethernet  are  allowed  but  shall  not 
limit  XIF-DATA  programming. 

4. 2.3.2  Size  •  i.  n  u 

Due  to  small  spaces  available  in  tactical  aircraft  for  instrumentation,  the  bus  monitor  shall  be 

no  larger  than  256  in^  exclusive  of  mounting  tabs  and  mating  connectors. 

4.2.3.3  Weight 

Given  the  size  requirements  in  4. 2.3. 2  ,  weight  is  not  an  issue. 

4.2.3.4  Mounting  •  .  „ 

Due  to  small  spaces  available  in  tactical  aircraft  for  instrumentation,  the  bus  monitor  shall 

have  all  connectors  located  on  one  face. 

4.2.3.5  Connectors 

The  connectors  used  by  the  bus  monitor  shall  be  EMI  shielded  and  have  a  positive  lock 
mechanism. 

4.2.3.6  Color 

The  color  of  the  bus  monitor  shall  be  orange  to  identify  it  as  test  equipment. 

4.2.3.7  Reliability 

Reliability  shall  be  measured  in  Mean  Time  Between  Failures  (MTBF).  The  bus  monitor 
shall  have  an  MTBF  greater  than  1000  hours. 

4.2.4  Airborne  uninhabited  environment 

Unless  otherwise  specified,  the  bus  monitor  shall  conform  to  the  requirements  when  subjected  to 
the  environmental  conditions  listed  below. 

4.2.4.1  Storage  Temperature 
-55°Cto+100°C 

4.2.4.2  Operating  Temperature 

The  thermal  design  shall  take  into  consideration  ambient  air  using  convection  and  radiation 
only.  Forced  air  and  heat  sinking  shall  not  be  required. 

-55°C  to  +85°C 

4.2.4.3  Pressure  Altitude 
-1000  feet  to  +85,000  feet 
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4.2.4.4  Temperature/Altitude 

Combined  conditions  of  +85°C  and  85,000  feet 

4. 2.4. 5  Relative  Humidity 

99  percent,  condensing 

4. 2. 4. 6  Vibration 

•  5  to  14  Hz  at  0.20  inch  double  amplitude 

■  14to20Hzat0.10  inch  double  amplitude 

■  20  to  33  Hz  at  2g  acceleration 

■  33  to  74  Hz  at  0.036  inch  double  amplitude 

■  74  to  2000  Hz  at  1  Og  acceleration 

4.2.4. 7  Shock 


Woithiuess  C  -  ■ ?  ;• ,  / 

Operational*  .‘v 

Peak  Acceleration;  40g,  each  axis 

Method  5 1 6.4,  procedure  5 . 

Peak  acceleration:  20g 

Duration:  6  to  9  milliseconds 

Axis:  all  axes 

Method  516.4,  procedure  1. 

4.2.4.8  Electromagnetic  Compatibility  Limits 

Conducted  Emission  (CE03),  Radiated  Emissions  (RE02)  and  Radiated  Susceptibility  (RS03) 
perMIL-STD-461C. 

4.2.4.9  Sand  and  Dust 

The  equipment  shall  withstand,  in  both  operating  and  non-operating  condition,  exposure  to 
sand  and  dust  particles  as  outlined  in  MIL-STD-810E. 

4.2.4.10  Fungus 

The  equipment  shall  withstand,  in  both  operating  and  non-operating  condition,  exposure  to 
fungus  growth  as  encountered  in  tropical  climates.  In  no  case  shall  overall  spraying  of  the 
equipment  be  necessary.  If  it  can  be  shown  non-nutrient  materials  are  used,  fungus  test  may 
be  accomplished  by  analysis. 

4.2.4.11  Salt  Atmosphere 

The  equipment  shall  withstand,  in  both  operating  and  non-operating  condition,  exposure  to 
salt-sea  atmosphere. 

4.2.4.12  Explosive  Conditions 

The  equipment  shall  not  cause  ignition  of  an  ambient-explosive-gaseous  mixture  with  air 
when  operating  in  such  an  atmosphere. 

4.3  Requirements  Correlation 

Table  1  correlates  the  requirements  listed  in  section  4.2  with  the  states  and  modes  listed  in 
section  4.1 .  The  requirements  apply  to  the  states  and  modes  as  indicated. 
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Table  1  Requirements  Correlation 


Requirement 

States  and  Modes  ■ 

.Prograinf; 

Diagnostic 

Validate  Truth  ‘ 

Fibre  Channel  Avionics  Bus 

Interference  with  avionics  operation 

Avionics  Compatibility 

y/' 

Number  of  Avionics  Interfaces 

V 

✓ 

Number  of  Bus  Messages 

TitF.  Data  Svstem 

T&E  Data  System  Compatibility 

V 

Validate  Mode  Data  Format 

V 

Truth  Mode  Data  Format 

y/' 

✓ 

Time  Tagging 

V 

y/ 

Power 

✓ 

y/' 

Louistics  _ _ _ - — - - - ^ - 1 

_ C - - — ^ — - - - 

Programming  ports 

Size 

V 

✓ 

✓ 

V' 

Mounting 

✓ 

V 

Connectors 

y^ 

V 

✓ 

Color 

y/' 

✓ 

✓ 

Reliability 

y/' 

✓ 

V 

Airborne  uninhabited  environment 

Storage  Temperature 

Operating  Temperature 

✓ 

✓ 

✓ 

Pressure  Altitude 

✓ 

y/ 

V 

Temperature/Altitude 

✓ 

✓ 

■/ 

V 

Relative  Humidity 

✓ 

✓ 

V 

Vibration 

V 

y/ 

Shock 

V 

✓ 

Electromagnetic  Compatibility  Limits 

V 

✓ 

✓ 

Sand  and  Dust 

V 

✓ 

y/' 

Fungus 

V 

y/ 

y/ 

y/ 

V 

Salt  Atmosphere 

V 

y/ 

V 

V 

Explosive  Conditions 

V 

V 

■/ 

5  Notes 

5.1  Acronyms 

EMI 

T&E 

XIF-DATA 

XIF-FC 


and  Abbreviations 

Electromagnetic  interference 
Test  &  Evaluation 

Project  unique  identifier  —  T&E  data  system  external  interface 

Project  unique  identifier  —  Fibre  Channel  avionics  system  external  interface 
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1  Scope 

This  trade  study  identifies  the  various  options  available  to  the  instrumentation  engineer  when 
interfacing  a  Fibre  Channel  Bus  Monitor  to  the  production  Fibre  Channel  Avionics  System. 

2  Overview 

The  Fibre  Channel  Avionics  Bus  Monitor  is  used  to  monitor  Fibre  Channel  avionics  busses 
located  on  weapons  platforms  for  test  and  evaluation  (T&E)  purposes  -  primarily  during 
developmental  testing. 

A  T&E  Data  System  acquires  data  during  a  test  or  mission.  This  data  is  recorded  for  post-flight 
analysis.  The  data  may  also  be  transmitted  to  a  ground  processing  facility  for  in-flight  data 
monitoring.  As  such,  the  T&E  data  system  must  be  invisible  to  the  operation  and  control  of  the 
aircraft.  The  T&E  data  system  typically  consists  of  independent  wiring,  data  acquisition  units, 
and  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed  and  the  aircraft  is 
returned  to  fleet  status.  The  data  system  may  also  be  known  as  an  instrumentation  system  or  a 
telemetry  system. 

As  can  be  seen  by  the  red  dashed  box  in  Figure  1,  a  bridging  system  is  needed  to  gather  the  data 
of  interest  from  the  production  avionics  system  and  format  the  data  into  something  useful  for  the 
T&E  data  system.  The  bus  monitor  conceptually  consists  of  two  parts.  The  first  part  is  the 
actual  interface  to  the  production  avionics  system  identified  as  a  bus  tap.  The  second  part  is  the 
unit  that  receives,  formats,  and  outputs  the  data. 


Figure  1  System  Relationships 
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3  Requirements 

The  Instramentation  Group  is  responsible  for  instrumenting  any  type  of  test  platform  in  the 
Navy’s  inventory.  Some  of  the  advanced  tactical  aircraft  are  installing  networked  based  fiber 
optic  busses  as  part  of  the  avionics  suite.  Part  of  the  flight  test  requirement  is  to  collect  data 
from  these  new  busses.  Since  these  networked  based  fiber  optic  busses  haven’t  shown  up  in  fleet 
assets  yet,  a  method  to  tap  into  these  busses  for  flight  test  has  yet  to  be  identified.  Research 
indicates  that  initial  installations  of  Fibre  Channel  Avionics  Systems  will  utilize  fiber  optic  cable. 
Since  this  is  a  more  stringent  requirement  than  purely  electrical  systems,  monitoring  busses  with 
fiber  optic  cables  will  be  the  requirement. 

4  Alternatives 

There  are  four  approaches  that  should  be  considered  for  tapping  into  a  networked-based  fiber 
optic  bus  for  flight  test  use. 

4.1  Developer’s  Approach 

During  development  of  the  avionics  system,  the  developer  must  monitor  many  of  the  same  types 
of  data  of  interest  during  flight  test. 

Pro 

■  Guaranteed  to  acquire  bus  data 

Con 

■  Don’t  know  what  the  approach  is  for  each  platform  /  manufacturer 

■  Developer  may  have  different  data  requirements 

■  May  require  different  approaches  for  each  aircraft 

■  May  not  be  independent  of  avionics  hard  ware/ soft  ware 

4.2  Individual  optical  bus  taps  at  each  node 

The  logical  configuration  of  a  switched  network  is  a  star,  with  the  switch  at  the  center.  To 
collect  bus  data,  an  optical  bus  tap  would  be  located  at  each  node  of  interest  either  at  the  swatch 
or  the  node  as  shown  in  Figure  2. 
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Pro 

■  Scaleable  -  add  additional  taps  as  needed 

■  Independent  of  platform  - 

■  Independent  of  avionics  hardware/software 

■  Acquires  all  required  data 

Con 

■  Optical  splices  are  difficult  to  make  under  the  best  conditions 

■  Optical  technology  is  still  evolving,  commercial  products  may  be  available  but  military 
capable  products  may  still  have  far  to  go 

■  May  require  active  taps  which  is  an  aircraft  failure  mode  if  instrumentation  fails 

■  Clumsy  and  cumbersome  to  mount  many  taps  in  one  area 


4.3  Replace  production  switch  with  instrumentation  switch 

The  logical  configuration  of  a  switched  network  is  a  star,  with  the  switch  at  the  center.  Replace 
the  production  switch  with  one  that  has  one  or  more  instrumentation  ports.  The  switch  can  be 
prograimned  by  the  instrumentation  group  to  grab  the  data  of  interest. 

Pro 

■  Acquires  all  required  data 

■  Independent  of  platform  (provided  avionics  utilizing  switched  fabric  architecture) 

■  Independent  of  avionics  hardware/software 

Cod 

■  Impacts  operational  characteristics  of  avionics  system 

Flight  clearance  may  be  impossible  to  obtain 

■  Aircraft  would  need  to  be  re-certified  upon  each  installation  (costly  and  time  consuming) 

4.4  Avionics  switch  with  built-in  instrumentation  support 

During  avionics  design,  petition  the  program  office  to  install  a  switch  for  production  that  has 
instrumentation  capabilities  built  in.  The  switch  can  be  programmed  by  the  instrumentation 
group  to  grab  the  data  of  interest. 

Pro 

■  Guaranteed  to  acquire  some  to  all  required  data 

■  Very  easy  to  monitor  I  as 

■  No  installation  or  flight  clearance  issues 
Con 

■  As  avionics  matures,  instrumentation  ports  may  be  used  for  production 

■  Limited  number  of  ports  may  limit  data  availability 

■  Non-independent  of  avionics  hardware/software 

■  May  get  some  platforms  to  buy  into  concept,  still  need  approach  for  others 

5  Criteria 

The  criteria  with  which  to  select  the  bus  tap  method  are  listed  in  below.  The  scoring  method  and 
weightings  are  shown  in  Table  1 . 


4 


5.1  Affects  production  system 

The  goal  of  instrumentation  is  to  monitor  what  is  going  on  without  affecting  it.  Although  there 
are  some  instances  when  affecting  the  system  under  test  is  not  critical;  they  are  few  and  far 
between  and  almost  never  apply  to  production  avionics  systems. 

5.2  Installation  Timeliness 

The  capability  to  install  or  update  a  bus  monitor  system  in  a  timely  fashion  is  paramount.  When 
test  assets  are  not  flying,  they  are  not  making  money  (i.e.  distributing  the  flight  costs  across  more 
flight  hours).  There  are  plenty  of  items  that  drive  the  down  time  of  the  aircraft.  Stocking  up  on 
common  long  lead  items  is  one  way  to  manage  the  down  time.  Another  way  is  to  avoid  time 
consuming  installation  processes. 

5.3  Independent  from  production  system 

Another  goal  of  instrumentation  is  to  remain  independent  from  the  system/sub-system  under  test. 
When  the  system/sub-system  is  the  avionics,  independence  is  important.  However,  when  testing 
other  systems,  avionics  data  is  often  used  as  truth  data  and  therefore  not  as  critical. 

5.4  Ease  of  subsequent  flight  clearance  sign  off 

The-first  time  a  Fibre  Channel  avionics  bus  monitor  is  used,  a  significant  flight  clearance/safety 
of  flight  review  "will  result.  What  is  important  is  the  review  process  for  subsequent  installations. 

5.5  Availability  of  required  data 

Some  approaches  may  limit  the  data  acquisition  to  a  select  number  of  nodes  due  to  limitations  in 
the  acquisition  method.  Additional  data  would  be  impossible  or  require  another  data  system. 

5.6  Ease  of  physical  installation 

With  most  instrumentation,  the  time  required  to  install  a  data  system  is  scrutinized.  The 
customer  wants  their  test  assets  flying  as  much  as  possible.  The  number  of  components  and  the 
space  they  require  translate  directly  to  installation  time  and  costs. 


Table  1  Criterion  Scoring  and  Weighting 


.;eriterM»'.5?^  i ^  . 

/•,  .Units'T^i'r 

liWeiahfioiair 

Affects  production  system 

Y/N 

0/3 

30% 

Timeliness  (Install  when  a/c  shows  up  in  hanger) 

L/M/H 

1/2/3 

20% 

Independent  from  production  system 

15% 

Ease  of  subsequent  flight  clearance  sign  off  (not  first  time) 

L/M/H 

1/2/3 

15% 

Availability  of  required  data  (are  there  data  limitations) 

L/M/H 

1/2/3 

10% 

Ease  of  physical  installation 

L/M/H 

1/2/3 

10% 

6  Comparison 

The  alternatives  were  evaluated  using  the  units  listed  in  Table  1  and  are  summarized  in  Table  2. 
Each  alternative  was  scored  using  ‘0’  or  ‘3’  for  yes/no  answers  and  ‘1’,  ‘2’,  or  ‘3’  for 
low/medium/high  answers.  Table  3  shows  the  raw  score  and  weighted  score  for  each  alternative. 
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Table  2  Evaluation  of  Alternatives 


.Criterioir'"- ‘  ^  ^  ‘ 

,■  .Units 

. ,  Developer 

'  '  ' 

#%■■■ 

Affects  production  system 

Y/N 

N-3 

N-3 

N-3 

Y-O 

Timeliness 

L/M/H 

M-2 

H-3 

H-3 

L-l 

Independent  from  production  system 

L/M/H 

H-3 

H-3 

M-2 

L-l 

Ease  of  subsequent  flight  clearance  sign  off 

L/M/H 

L-  1 

H-3 

L-l 

H-3 

Availability  of  required  data 

L/M/H 

L-  1 

H-3 

M-2 

M-2 

Ease  of  nhvsical  installation 

L/M/H 

L-  1 

L-l 

M-2 

H-3 

Raw  Score 

11 

16 

13 

10 

Table  3  Scoring  of  Alternatives 


(18  max)  i  ; 

Developer’s  Approach 

11 

2.1 

_  ,  JT  ■  ^  - - - — - - 

Individual  fiber  optic  bus  taps  at  each  node 

16 

2.8 

R enlace  production  switch  with  instrumentation  switch 

13 

2.4 

Avionics  switch  with  built-in  instrumentation  support 

10 

1.3 

7  Conclusion 

The  ‘individual  fiber  optic  bus  taps’  alternative  was  the  winner,  which  makes  sense  when 
considering  this  is  the  current  paradigm  for  acquiring  Mil-Std-1553  bus  data.  The  important 
point  about  this  trade  study  was  its  emphasis  on  being  able  to  instrument  a  Fibre  Chaimel 
avionics  system  when  it  shows  up  in  the  hanger.  Some  quick  projects  need  to  be  out  the  door  in 
a  matter  of  weeks.  The  ‘individual  taps’  will  ensure  these  requirements  can  be  met.  However,  it 
may  not  be  the  most  cost  effective.  As  the  technology  matures  and  aircraft  are  delivered,  it  may 
turn  out  the  other  alternatives  (by  themselves  or  in  conjunction  with  each  other)  may  be  a  very 
effective  80%  or  better  solution. 

A  sensitivity  analysis  was  performed  on  the  results  to  ensure  the  choice  of  either  the  utility  curve 
or  the  weighting  for  a  particular  element  did  not  affect  the  outcome  between  two  or  more  closely 
matched  alternatives.  For  this  study,  the  top  score  was  more  than  10%  of  ftill  scale  above  the 
closest  challenger,  which  was  a  good  overall  indicator  of  insensitivity.  To  further  check  for 
sensitivity,  each  criterion  was  successively  zeroed  out.  With  the  elimination  of  each  successive 
criterion  the  order  of  the  alternatives  changed,  but  the  winner  remained  constant.  This  shows 
one  criterion  did  not  drive  the  results.  Table  4  shows  the  results  of  zeroing  the  criteria.  For  each 
criterion  zeroed,  read  across  the  table  for  the  results. 
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Table  4  Sensitivity  Results 


Criterion  Zeroed^. 

'  <  '  ,  Results 

CO .  ’ .  ' 

’  v'-’v  u',. 

s' 

iJfi. 

Affects  production  system 

1.6 

2.6 

2.0 

2.0 

Timeliness 

1.8 

2.6 

1.8 

Independent  from  production  system 

1.6 

2.6 

1.8 

Ease  of  subsequent  flight  clearance  sign  off 

2.0 

2.6 

2.4 

1.4 

Availability  of  required  data 

[H^HI 

2.6 

2.2 

1.6 

Ease  of  physical  installation 

2.2 

1.4 
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1  Scope 

This  trade  study  identifies  several  technologies  that  could  be  used  to  develop  a  flight  qualified 
Fibre  Channel  Bus  Monitor. 

2  Overview 

The  Fibre  Channel  Avionics  Bus  Monitor  is  used  to  monitor  Fibre  Channel  avionics  busses 
located  on  weapons  platforms  for  test  and  evaluation  (T&E)  purposes  -  primarily  during 
developmental  testing. 

A  T&E  Data  System  acquires  data  during  a  test  or  mission.  This  data  is  recorded  for  post-flight 
analysis  The  data  may  also  be  transmitted  to  a  ground  processing  facility  for  in-flight  data 
monitoring.  As  such,  the  T&E  data  system  must  be  invisible  to  the  operation  and  control  of  file 
aircraft.  The  T&E  data  system  typically  consists  of  independent  wiring,  data  acquisition  units, 
and  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed  and  the  aircraft  is 
returned  to  fleet  status.  The  data  system  may  also  be  known  as  an  instrumentation  system  or  a 

telemetry  system. 

As  can  be  seen  by  the  red  dashed  box  in  Figure  1,  a  bridging  system  is  needed  to  gather  the  data 
of  interest  fi'om  the  production  avionics  system  and  format  the  data  into  something  useful  for  the 
T&E  data  system.  The  bus  monitor  conceptually  consists  of  two  parts.  The  first  part  is  the 
actual  interface  to  the  production  avionics  system  identified  as  a  bus  tap.  The  second  part  is  the 
unit  that  receives,  formats,  and  outputs  the  data. 


Figure  1  System  Relationships 
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3  Requirements 

A  Fibre  Channel  Bus  Monitor  must  be  both  functional  and  cost  effective. '  Functionality  includes 
anticipating  future  growth  needs  of  the  product.  There  is  one  area  that  drives  both  of  these 
requirements  directly  from  the  start  of  the  design  -  the  development  technology.  Acquisition 
reform  and  the  draw-down  of  Defense  spending  requires  the  Instrumentation  Community  to 
consider  how  they  use  their  funding.  Research  has  shown  that  only  40%  of  the  lifecycle  cost  of  a 
product  occurs  during  development.  The  majority  of  the  life  cycle  cost  is  in  the  recurring  and 
supportability/maintainability  areas.  In  order  to  keep  the  total  cost  of  ownership  low;  we  need  to 
consider  leveraging  off  developments  and  purchasing  power  available  in  other  industrial  areas  - 
like  the  embedded  PC  market. 

4  Alternatives 

There  seem  to  be  four  rea’  alternatives  in  the  technology  to  design  and  build  a  flight  quality  Fibre 
Channel  Bus  Monitor.  The  first  three  were  chosen  from  basic  industry  awareness  and  looking 
through  several  issues  of  RTC  magazine.  RTC  magazine  specializes  in  embedded  and  real-time 
computer  systems.  As  can  be  seen  by  the  selection  criteria,  the  goal  was  to  get  a  product  that 
was.  cost-effective,  viable,  and  supportable.  I  ruled  out  concepts  not  supported  by  a  standard, 
industry  consortium,  or  were  just  emerging  as  standards.  Custom  design  was  added  since  they 
have  been  the  option  used  in  this  industry  for  the  past  30  years  and  should  be  considered. 

4.1  PC/104  &  PC/1 04+ 

PC-104  has  been  around  for  awhile.  It  is  small  formfactor  board  measuring  approximately  4 
inches  square.  Combinations  of  cards  can  be  stacked  on  top  of  each  other  to  gain  greater 
functionality.  PC/104  utilizes  both  8  and  16  bit  versions  of  the  ISA  bus  (5  MB/s)  for 
communication  between  the  cards.  As  the  bus  throughput  requirements  increased,  a  PCI  bus 
(132  MB/s)  connector  was  added  to  the  PC/104  card  turning  it  into  a  PC/104+  card.  Support  for 
the  PCI  bus  is  limited  to  a  bus  width  of  32  bits.  The  stacking  concept  is  shown  in  Figure  2. 
Although  PC/104  modules  have  been  manufactured  since  1987,  a  formal  specification  was  not 
published  until  1992.  Like  the  original  PC  bus  itself,  PC/104  is  thus  the  expression  of  a  de  facto 
standard  rather  than  the  invention  and  design  of  a  committee.  The  PC/104  Consortium  is 
responsible  for  maintaining  the  PC/104  and  PC/1 04+  standards  until  the  IEEE  completes  the 
proposed  IEEE-P996.1  version. 


Figure  2  PC/104  Stack  Example  (3.6  x  3.8  inches) 
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4.2  PCI  Mezzanine  Card  (PMC) 

The  PCI  Mezzanine  Card  (PMC)  has  been  around  since  1994.  It  has  increased  market  share  and 
become  the  de  facto  large  expansion  module  formfactor  for  VME  (VersaModule  Eurocard)  and 
Compact  PCI.  It  is  approximately  30%  larger  than  PC/104  measuring  approximately  3  inches  by 
6  inches.  The  relatively  large  size  of  PMC  for  a  mezzanine  card  was  a  great  boon  in  the 
beginning.  Now  with  entire  boards  being  placed  within  a  single  chip,  many  PMC  single  function 
boards  are  overkill  with  large  amounts  of  unused  real  estate.  In  specialized  applications  where 
conduction  cooling  and  ruggedization  typically  require  more  space,  the  size  may  again  be  a 
strength.  The  bus  I/O  on  the  PMC  card  is  a  full  64  bit  PCI  bus  operating  at  66  MHz.  PMC 
enthusiasts  are  also  in  work  to  create  a  new  Processor  PMC  (P-PMC)  variant  by  adding  support 
for  a  processor  on  the  card.  PMC  is  governed  by  the  standard  IEEE-1386.1.  Figure  3  shows  an 
example  of  the  PMC  card. 


Figure  3  PMC  Card  Example  (3  x  5.9  inches) 

4.3  Industry  Pack  (IP) 

The  Industry  Pack  (IP)  card  was  one  of  the  first  mezzanine  cards.  It  was  originally  designed  to 
solve  space  and  I/O  issues  on  a  crowded  VME  card.  The  role  of  the  mezzanine  card  has  evolved 
to  become  one  of  flexibility.  The  card  itself  doesn’t  support  the  prevalent  ISA  and  PCI  busses. 
It’s  8  bit  16  MB/s  bus  limits  it’s  applicability  to  traditional  industrial  automation  application 
types  such  as  A/D  conversion,  motion  control,  and  discrete  I/O.  Mil-Std-1553  and  Anne  429 
applications  seem  to  abound  in  this  standard.  Figure  4  shows  an  example  of  the  IP  card. 


Figure  4  IP  Card  Example  (1.8  x  3.9  inches) 
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4.4  Custom  Design 

This  category  can  cover  a  large  area.  Technically  any  of  the  preceding  categories  that  may  need 
a  special  interface  designed  could  be  classified  as  custom.  For  the  purposes  of  this  trade  study, 
the  term  ‘custom  design’  will  be  used  to  indicate  a  substantially  ‘from  scratch’  design.  The  card 
size,  connectors,  busses,  etc  will  all  be  chosen  to  favor  the  performance  side  of  the 
cost/performance  trade  space. 

5  Criteria 

The  criteria  with  which  to  select  the  bus  tap  method  are  listed  in  below.  The  scoring  method  and 
weightings  are  shown  in  Table  2.  The  utility  relationship  for  each  criterion  is  listed  at  the 
conclusion  of  each  paragraph. 

5.1  Backplane  Bus  Speed 

The  speed  of  the  backplane  is  the  single  best  indicator  in  determining  the  applicability  of  a 
technology  in  a  data  intensive  application  like  this  one.  With  Fibre  Channel  having  a  basic  data 
rate.of  100  MB/s,  a  very  light  data  loading  of  20%  would  require  a  minimum  rate  of  20  MB/s 
(assuming  no  overhead).  Fibre  Channel  and  other  telecommunications  standards  are  currently 
striving  for  1000  MB/s  rates.  When  these  higher  rates  start  showing  up  in  the  commercial 
markets,  a  technology  that  has  room  to  grow  as  data  requirements  increase  is  critical.  When  a 
major  weapons  program  was  researched  recently;  it  showed  an  exponential  growth  in  data  rate 
requirements  over  the  last  20  years.  There  is  no  reason  to  indicate  this  will  change  now. 

UTILITY:  <20  MB/s  — -  >500  MB/s  {linear} 

5.2  Technology  Availability 

The  point  of  this  product  is  to  gather  data  from  avionics  Fibre  Channel  interfaces.  In  order  to 
make  this  cost  effective,  commercial  Fibre  Channel  bus  adapters  must  be  available.  The 
availability  of  a  Fibre  Channel  adapter  will  get  a  high  score.  In  the  absence  of  a  Fibre  Channel 
capability,  the  availability  of  another  telecommunication  or  computer  standard  like  Ethernet  or 
Small  Computer  System  Interface  (SCSI)  will  get  a  medium  score.  The  rationale  is  that  it  is 
conceivable  product  lines  could  be  expanded  to  include  Fibre  Channel  if  they  are  already  in  the 
telecommunications  or  data  storage  market.  For  the  custom  design,  a  similar  rationale  applies 
concerning  the  capabilities  of  the  development  staff. 

UTILITY:  L  -  Any  products  M  -  Any  telecom/storage  H  -  Fibre  Channel  {discrete} 

5.3  Environment  /  Ruggedability 

One  of  the  issues  with  using  commercial  products  in  a  flight  test  environment  is  their 
susceptibility  to  the  vibration  and  temperature  extremes.  The  availability  of  products  in  a  rugged 
format  will  be  used  to  assess  this  criterion.  A  rugged  format  means  less  development  work  is 
spent  trying  to  adapt  it  for  use  in  a  harsh  environment.  Based  on  the  technology  availability 
found  in  section  5.2,  an  assessment  will  be  made  as  to  the  availability  of  a  ruggedized  capability. 
For  example:  If  the  IP  alternative  was  found  in  5.2  to  have  telecommunications  products 
available  and  further  research  shows  the  most  rugged  version  to  be  industrial  grade  -  then  as 
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shown  in  Table  4,  the  score  would  be  ‘5’.  By  definition,  the  custom  design  will  have  a  militarily 
rugged  Fibre  Channel  solution. 

Table  1  UTILITY  Function  for  Environment  /  Ruggedability 

Results  from  5.2 
Most  rugged  product 

Score 


Any  Products 

Telecom/Storage  Products 

Fibre  Channel  Products 

C  l  M 

C  I  M 

C  I  M 

C  Commercial  I  Industrial  M  Military  - 1 

5.4  Supportability/ User  Base 

Just  as  important  as  the  purchase  cost  is  the  life  cycle  support  cost.  A  major  component  to  the 
life  cycle  cost  is  some  measure  of  platform  supportability.  When  an  upgrade  is  required,  will 
this  platform  still  be  in  use?  An  indicator  of  future  supportability  is  the  size  of  the  installed  user 
base  at  the  present.  A  larger  user  base  now  will  provide  the  impetus  for  design  upgrades.  It  also 
means  more  maintenance  work  that  can  be  spread  across  more  companies  keeping  the  pnces 
down  A  sampling  of  vendors’  products  will  be  used  to  assess  the  current  user  base  while 
adherence  to  commercial  standards  will  help  to  predict  the  amount  of  future  users.  The  custom 
design  will  be  scored  a  Tow’  by  default,  considering  the  size  of  the  other  markets. 

UTILITY:  L  —  M  —  H  {discrete,  relative  to  each  other} 
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size  is  an  important  consideration  in  any  test  environment.  Smaller  size  allows  for  easier 
installation  when  space  is  a  premium.  Larger  units  may  require  the  removal  of  production 
eauipment.  The  system  under  test  may  be  affected  without  these  production  systems  running. 
Calculating  the  size  of  a  given  design  is  difficult  without  actually  doing  the  design.  For  this 
trade  study,  the  individual  card  size  vsall  be  used  as  the  metric.  For  the  custom  design,  ^ 
average  sample  of  Mil-Std-1553  bus  monitors  will  be  used  since  their  function  is  similar.  While 
size  is  important  and  is  why  it  is  listed  as  a  criterion  to  begin  with,  all  of  these  technologies  are 
of  a  reasonable  size.  This  was  given  low  weighting  to  provide  an  edge  to  the  smaller  of  evenly 
matched  choices,  not  to  drive  the  decision. 

UTILITY:  >20  sq  in  — -  <  5  sq  in  {linear} 


Table  2  Criterion  Scoring  and  Weighting 


>■-  UhitSi 

l-Scjpjpi^ 

Backplane  Bus  Speed 

<20  MB/s  — -  >500  MB/s  {linear} 

0-10 

35% 

Technology  Availability 

L  -  Any  products 

M  -  Any  telecom/storage  products 

H  -  Fibre  Channel  {discrete} 

0/5/10 

25% 

Environment  /  Ruggedability 

Any  products  (C  / 1  /  M) 

Any  telecom/storage  products  (C  / 1  /  M) 

Fibre  Channel  (C  / 1  /  M) 

C-Com  I-Ind  M-Mil  (discrete} 

0/1/2 

4/5/6 

8/9/10 

20% 

Supportability  /  User  Base 

L  —  M  —  H  {discrete,  relative} 

0/5/10 

15% 

Size  J 

>20  sq  in  — -  <  5  sq  in  {linear} 

0-10 

5% 
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6  Comparison 

The  alternatives  were  evaluated  using  the  units  listed  in  Table  2  and  are  summarized  in  Table  3. 
Each  alternative  was  scored  on  a  10-point  scale.  The  individual  raw  scores  were  multiplied  by 
the  weighting  percentage  and  added  together.  The  final  weighted  scores  as  shown  in  Table  3 
have  a  possible  high  score  of  1 0. 


Table  3  Evaluation  of  Alternatives 


7 1  ,4''  -4  , 

4  ’  [-1'- 
.^4'.  ’ 
''  ^  1' 

GritenoD--"" ^  - 

iSPili 

Backplane  Bus  Speed 

MB/s 

132 

528 

16 

132N0tel 

Raw  Score 

2.3 

10.0 

0.0 

2.3 

Technology  Availability 

no  units 

M 

H 

L 

L 

Raw  Score 

5 

10 

0 

0 

Environment  /  Ruggedability 

no  units 

T-M 

F-M 

A-M 

F-M 

Raw  Score 

6 

10 

2 

10 

Supportability  /  User  Base 

no  units 

M 

H 

M 

L 

Raw  Score 

5 

10 

5 

0 

Size 

in^ 

13.68 

17.7 

7.0 

6.25'"°''^ 

Raw  Score 

4.2 

1.5 

8.7 

9.1 

Total  Raw  Score 

22.5 

41.5 

15.7 

21.5 

Weighted  Score  (out  of  10) 

Note  1 :  It  is  assumed  a  custom  design  would  utilize  a  32  bit  PCI  bus  or  equivalent 
Note  2:  Used  common  miniature  data  acquisition  card  size  of  2.5x2.5. 


7  Conclusion 

PC/104  was  the  favorite  going  into  the  trade  study  due  to  the  variety  of  products  available. 
However  PC/104  was  hurt  by  its  lack  of  Fibre  Channel  products.  PMC  not  only  had  the 
ruggedized  Fibre  Channel  boards,  but  had  the  most  offerings  of  products  in  general.  The  notable 
exception  is  the  lack  of  a  single  board  computer  (SBC)  in  the  PMC  formfactor.  Any  processing 
would  have  to  be  done  on  the  carrier  card.  That  should  soon  be  remedied  as  there  is  work  in  the 
standards  group  to  include  a  processor  PMC  board  (called  P-PMC).  The  Industry  Pack  choice 
was  extremely  disappointing.  There  is  a  fair  amount  of  ruggedized  Mil-Std-1553  boards 
available,  but  that  seems  to  be  about  it.  IP  products  were  very  hard  to  find.  One  of  the  big 
drawbacks  for  IP  is  the  slow  bus.  There  have  been  discussions  in  the  standards  body  of  mapping 
Compact  PCI  to  the  I/O  on  the  IP  card.  The  custom  design  is  the  old  standby.  It  will  do  the  job. 
The  only  question  is... can  we  afford  it?  Based  on  these  results,  PMC  is  the  better  choice.  It 
should  be  able  to  do  the  job  with  minimal  ‘glue’  logic  to  tie  the  design  together. 
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A  sensitivity  analysis  was  performed  on  the  results  to  ensure  the  choice  of  either  the  utility  curve 
or  the  weighting  for  a  particular  criterion  did  not  affect  the  outcome  between  two  or  more  closely 
matched  alternatives.'  For  this  study,  the  top  score  was  more  than  50%.of  full  scale  above  the 
closest  challenger,^  which  was  a  good  overall  indicator  of  insensitivity.  To  further  check  for 
sensitivity,  each  criterion  was  successively  zeroed  out.  With  the  elimination  of  each  successive 
criterion  the  order  of  the  #ematives  changed,  but  the  winner  remained  constant.  This  shows 
one  criterion  did  not  drive  the  results.  Table  4  shows  the  results  of  zeroing  the  criteria.  For  each 
criterion  zeroed,  read  across  the  table  for  the  results. 


Table  4  Sensitivity  Results 


-  1 

Backplane  Bus  Speed 

7,9  - 

.  3.9 

4S 

Technology  Availability 

4.4 

7.9  1 

3.9 

5.4 

Environment  /  Ruggedability _ 

4.1  : : 

7.9  ^ 

.  34.-' 

Suonortability  /  User  Base 

4.4 

7.9 

2.7 

5.4 

_ t-I- . . . . . — - - - - 

Size  . 

4.6 
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1  Detailed  Project  Description 

1.1  Background 

Traditionally,  airframes  were  designed  without  any  thought  of  ways  to  instrument  them.  Once 
the  airframe  was  built,  requirements  were  turned  over  to  the  flight  test  instrumentation 
department  to  find  a  way  to  monitor  the  data  necessary  for  testing  (the  term  afterthought 
comes  to  mind).  This  was  not  necessarily  a  bad  thing  -  then.  The  economics  was  a  25  million- 
dollar  instrumentation  budget  was  noise  to  a  multibillion-dollar  development  budget.  During  the 
past  8-10  years,  that  has  begun  to  change  for  a  couple  of  reasons.  Defense  dollars  are 
diminishing  and  the  airframes  are  becoming  a  lot  more  complex.  The  result  has  been  a  push-pull 
effect  to  integrate  the  test  instrumentation  engineers  earlier  in  the  program.  The  developer  wants 
to  pull  the  test  instrumentation  engineer  in  to  save  Test  &  Evaluation  (T&E)  costs.  The  test 
instrumentation  engineer  wants  to  push  their  way  in  due  to  the  complexity  of  the  systems  that 
need  monitoring. 

The  current  state  of  the  art  has  airfi-ame  developers  augmenting  the  production  avionics  data 
buses  with  high-speed  fiber  optic  networks  (in  many  cases  using  Fibre  Channel).  As  these  fiber 
optic  networks  are  being  installed  in  airframes,  the  test  instrumentation  engineer  will  be  expected 
to  safely  monitor  the  data  flowing  through  them.  Unlike  many  of  the  systems  in  the  past, 
successful  monitoring  will  require  an  engineering  analysis  long  before  any  data  is  required.  The 
timing  for  this  project  is  perfect.  Networks  are  now  being  put  in  several  of  the  major  airfi-ames 
where  the  designs  could  be  tweaked  to  facilitate  the  instrumentation  system.  These  systems  are 
far  enough  down  the  road  that  knowledge  gained  now  will  help  the  community  prepare. 

1.2  Need  for  System 

Acquisition  Reform  has  allowed  the  Department  of  Defense  (DoD)  to  quickly  integrate  state  of 
the  art  commercial  products  into  the  weapons  platforms.  One  such  area  is  the  integration  of 
network  technology  into  the  production  avionics  suite.  There  is  a  concern  this  is  happening 
faster  then  the  Test  and  Evaluation  community  can  react  with  proper  instrumentation  practices 
and  products. 

For  the  past  20  years,  the  avionics  bus  used  on  military  aircraft  has  been  Mil-Std-1553  (1553). 
Because  it  utilized  a  ‘bus  architecture’  where  all  devices  are  connected  to  a  central  cable, 
monitoring  the  bus  data  for  Test  &  Evaluation  purposes  was  relatively  simple.  Regardless  of 
where  the  bus  tap  was  made,  all  of  the  data  was  available  as  illustrated  in  Figure  1 .  The  data 
requirements  of  today’s  aircraft  are  so  large  that  it  overwhelms  the  1553  bus.  For  many  airframe 
manufacturers  Fibre  Channel  is  the  solution. 

Fibre  Channel  is  currently  4000  times  faster  than  1553  with  plans  to  go  faster.  Fiber  Channel 
operates  in  a  point-to-point  architecture.  A  node  on  the  system  will  communicate  through  a  port 
with  only  one  other  port.  Special  units  called  ‘switches’  receive  data  on  one  port  and  send  data 
out  on  another  port  to  create  what  the  industry  terms  a  ‘fabric’.  Figure  2  shows  a  typical 
switched  fabric  architecture  used  with  Fibre  Channel.  The  cloud  represents  the  uncertainty  as  to 
where  the  bus  tap  would  actually  be  made.  The  speed  and  architecture  differences  between  1553 
and  Fibre  Channel  require  the  instrumentation  community  to  develop  a  new  approach  to  capture 
bus  data  under  this  paradigm. 
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Figure  1  Monitoring  1553  (Bus  Architecture) 


Figure  2  Monitoring  Fibre  Channel  (Switched  Fabric  Architecture) 


1.3  Project  Objectives 

Through  this  project,  I  expect  to  lay  the  groundwork  for  an  avionics  bus  monitor  development 
program.  The  final  report  will  be  submitted  for  release  to  the  public.  The  A-Spec  and  other 
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supporting  documents  should  prove  useful  for  a  company  looking  for  a  product  to  insert  into 
their  Internal  Research  and  Development  (IRAD)  program.  Alternately  the  results  of  this  project 
could  be  used  as  a  baseline  for  a  Small  Business  Innovative  Research  (SB-IR)  project. 

2  Previous  Work 

The  issue  of  monitoring  a  networked  avionics  bus  first  came  to  light  about  two  years  ago. 
During  that  time,  the  Navy  was  leading  a  tri-service  project  on  finding  a  fast  commercial 
communications  bus  for  the  instmmentation  community.  After  much  research  and  a  very 
rigorous  3-tiered  trade  study,  Fibre  Channel  was  announced  as  the  likely  solution.  More 
information  about  Fibre  Channel  was  needed  so  we  started  attending  the  bi-monthly  Fibre 
Channel  Standard  working  meetings.  The  sub-committee  that  held  our  interest  was  the  Fibre 
Channel  Avionics  Environment  (FC-AE).  We  were  learning  about  the  capabilities  of  Fibre 
Channel  from  a  group  intent  on  operating  a  Fibre  Channel  network  in  the  same  environment. 
We  were  ecstatic  over  the  synergy  that  could  be  gained  from  a  market  as  broad  as  Storage  Area 
Networks  (SAN)  and  the  avionics  group  looking  to  make  it  more  robust.  It  dawned  on  us  that  if 
successful;  we  would  need  to  monitor  the  data  on  the  bus.  Discussions  with  the  sub-committee 
members  as  to  how  they  intended  to  monitor  the  data  were  the  basis  for  many  of  the  initial 
insights  and  options.  One  group  in  particular  decided  to  use  an  instrumentation  capable  switch. 
Since  they  were  the  ones  building  the  aircraft  and  selecting  the  data  to  monitor,  they  didn’t  have 
the  same  uncertainties  we  did  as  to  the  availability  of  the  instrumentation  ports  or  variability  of 
the  data  requirements. 

3  Requirements  Analysis 

A  requirements  analysis  was  performed  which  consisted  of  the  following  documents. 

3.1  Statement  of  Need 

A  Statement  of  Need  was  produced  as  part  of  the  requirements  analysis.  The  need  was 
addressed  from  the  perspective  of  monitoring  avionics  data  throughout  the  weapons  platform 
lifecycle.  This  document  was  the  result  of  personal  experience,  various  discussions  with 
personnel  in  the  Fibre  Channel  Avionics  community,  and  interviews  with  managers  associated 
with  the  four  major  T&E  ranges.  The  Statement  of  Need  is  included  as  Appendix  A  of  this 
report. 

3.2  Operational  Concept  Document 

The  operational  concept  document  addresses  four  important  topics  in  the  discussions  of  a  new  or 
improved  system. 

•  The  state  of  the  current  system 

•  The  concept  envisioned  for  the  new  or  improved  system 

•  How  the  new  system  will  be  utilized 

•  Impacts  the  new  system  will  have  on  current  operations 

The  important  point  to  come  out  of  this  document  is  the  idea  that  Fibre  Channel  will  not  replace 
Mil-Std-1553  in  military  aircraft  avionics  systems.  Instead,  Fibre  Channel  will  augment  Mil- 
Std-1553  avionics  systems.  This  is  good  news  to  the  Test  Ranges  since  it  implies  a  more  gradual 
shift  towards  fiber  optics  and  Fibre  Channel  rather  than  an  abrupt  one.  This  does  not  alleviate 
the  requirement  for  some  operations  personnel  to  get  up  to  speed  on  this  technology  now,  but 
does  lesson  the  urgency  for  the  majority.  The  Operational  Concept  Document  is  included  as 
Appendix  B  of  this  report. 


3 


3.3  External  Interface  Requirements 

There  were  two  significant  items  that  surfaced  as  a  result  of  identifying  the  external  interfaces. 
The  first  was  the  need  to  Understand  the  Open  System  Interconnect  (OSI)  model.  While  no  one 
actually  builds  systems  using- itf;the  OSI  model  is  how  most  systems. define  or  describe  their 
model.  The  second  item  has  to  do  with  specifying  interface  standards.  The  common  practice  is 
to  cite  the  current  revision  and  allow  for  future  ones.  Typically  the  newer  standards  further 
define  or  tighten  the  older  ones  and  therefore  are  backward  compatible.  When  dealing  with 
aircraft  power  standards,  a  similar  result  occurs  -  from  the  power  producer  perspective.  From  a 
power  consumer  perspective  a  device  must  be  able  to  heindle  the  worst  power  specification.  In 
this  case  that  means  the  oldest.  For  example,  a  newer  power  standard  may  allow  5-mV  ripple 
instead  of  the  previously  allowed  value  of  100-mV.  New  products  must  handle  power 
specifications  all  of  the  platforms  it  may  be  operated  on.  In  this  example,  it  must  be  designed  to 
the  older  100-mV  ripple  allowance.  The  External  Interface  Requirements  document  is  included 
as  Appendix  C  of  this  report. 

3.4  System  Requirements 

The  System  Requirements  document  identifies  several  required  states  and  modes  of  the  Fibre 
Channel  Bus  Monitor.  After  the  requirements  were  identified,  a  table  was  used  to  correlate  the 
requirements  to  the  states  and  modes  that  they  apply.  The  System  Requirements  document  is 
included  as  Appendix  D  of  this  report. 

4  System  Concept  Definition 

Collecting  data  from  an  avionics  bus  for  T&E  purposes  has  been  going  on  for  20  years. 
However,  there  are  three  areas  that  make  monitoring  Fibre  Channel  avionics  data  different  fi-om 
the  past:  networks,  optical  fiber,  and  gigabit  speeds.  A  bus  monitor  consists  of  two  major  sub¬ 
systems.  The  first  is  the  actual  interface  to  the  production  avionics  system  identified  as  a  bus  tap. 
The  second  is  the  main  unit  that  receives,  formats,  and  outputs  the  data. 

Tapping  into  Mil-Std-1553  avionics  busses  over  the  past  20  years  has  been  pretty  simplistic. 
Mil-Std-1 553  used  a  bus  architecture  which  means  that  no  matter  where  the  physical  tap  is  made, 
all  data  on  the  bus  is  available.  It  is  then  up  to  the  main  unit  to  filter  out  which  data  is  not 
wanted  and  pass  the  rest  on  to  the  data  system.  Fibre  Channel  uses  a  point-to-point  architecture. 
In  a  point-to-point  architecture,  data  is  only  sent  to  the  units  that  need  it.  Installing  a  tap  on  one 
leg  of  the  Fibre  Channel  bus  will  collect  data  either  going  to  or  from  that  one  unit. 

There  are  some  cases  where  a  single  point  bus  tap  would  work  in  a  Fibre  Channel  network.  It 
requires  a  couple  of  assumptions  about  the  capability  of  various  pieces  of  the  avionics  system. 
The  most  feasible  of  these  concepts  (the  instrumentation  capable  switch)  was  included  as  part  of 
the  bus  tap  trade  study.  Some  of  these  concepts  involved  fundamental  changes  to  the  avionics 
software  loads  that  control  the  operation  of  the  flight  control  systems.  An  example  is 
establishing  a  well-knoAvn  instrumentation  port  address  and  multicasting  data  of  interest  to 
include  this  address.  This  was  considered  to  be  unrealistic  since  the  Operational  Flight  Program 
(OFF)  would  have  to  be  reprogrammed  which  would  require  extensive  regression  testing  to 
ensure  the  modifications  didn’t  introduce  new  bugs  and  the  additional  data  traffic  wouldn’t  bog 
down  the  bus.  These  options  were  discarded  due  to  the  unnecessary  risk  factor  and  the  inability 
to  respond  to  changes  in  test  requirements  quickly. 
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The  bus  tap  trade  study  indicated  individual  optical  taps  were  the  best  single  solution.  This 
allows  the  system  to  capture  bus  data  when  the  bus  is  being  validated.  Bus  validation  is  the  most 
stringent  requirement  since  the  data  system  must  be  independent  of  the  system  under  test. 

Figure  3  shows  where  the  Fibre  Channel  Avionics  Bus  Monitor  (inside  red  dashed  box)  fits  into 
a  T&E  data  system.  This  figure  shows  how  the  new  Fibre  Channel  bus  monitor  would  be  a  node 
on  the  data  system  network  like  the  1553  bus  monitor  and  the  other  data  acquisition  nodes. 


Figure  3  System  Relationships 


5  Trade  Studies 

5.1  Bus  Tap  Method 

The  Instrumentation  Group  is  responsible  for  instrumenting  any  type  of  test  platform  in  the 
Navy’s  inventory.  Some  of  the  advanced  tactical  aircraft  are  installing  networked  based  fiber 
optic  busses  as  avionics  suite  upgrades.  Part  of  the  flight  test  requirement  is  to  collect  data  fi-om 
these  new  busses.  Since  these  networked  based  fiber  optic  busses  haven’t  shown  up  in  fleet 
assets  yet,  a  method  to  tap  into  these  busses  for  flight  test  has  yet  to  be  identified.  Research 
indicates  that  initial  installations  of  Fibre  Channel  Avionics  Systems  will  utilize  fiber  optic  cable. 
Since  this  is  a  more  stringent  requirement  than  purely  electrical  systems,  monitoring  busses  with 
fiber  optic  cables  will  be  the  requirement.  Four  approaches  were  identified  for  tapping  into  a 
networked-based  fiber  optic  bus  for  flight  test  use.  Table  1  shows  both  the  raw  score  and  the 
weighted  score  from  the  study.  For  more  information,  the  Bus  Tap  Method  Trade  Study  is 
included  as  Appendix  E  of  this  report. 
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Table  1  Bus  Tap  Method  Trade  Study  Results 


Alternative  , 

•..;,Wt  Score 

Developer’s  Approach 

11 

2.1 

Individual  fiber  optic  bus  taps  at  each  node 

16 

2.8 

Replace  production  switch  with  instrumentation  switch 

13 

2.4 

Avionics  switch  with  built-in  instrumentation  support 

10 

1.3 

5.2  Development  Technology 

A  Fibre  Channel  Bus  Monitor  must  be  both  functional  and  cost  effective.  Functionality  includes 
anticipating  future  growth  needs  of  the  product.  There  is  one  area  that  drives  both  of  these 
requirements  directly  from  the  start  of  the  design  -  the  development  technology.  Acquisition 
reform  and  the  draw-down  of  Defense  spending  requires  the  Instrumentation  Community 
consider  how  they  use  their  funding.  Research  has  shown  that  only  40%  of  the  lifecycle  cost  of  a 
product  occurs  during  development.  The  majority  of  the  life  cycle  cost  is  in  the  recurring  and 
supportability/maintainability  areas.  In  order  to  keep  the  total  cost  of  ownership  low;  we  need  to 
consider  leveraging  off  developments  and  purchasing  power  available  in  other  industrial  areas  - 
like  the  embedded  PC  market. 

There  seem  to  be  four  real  alternatives  in  the  technology  to  design  and  build  a  flight  quality  Fibre 
Channel  Bus  Monitor.  The  first  three  were  chosen  from  basic  industry  awareness  and  looking 
through  several  issues  of  RTC  magazine,  which  specializes  in  embedded  and  real-time  computer 
systems.  The  goal  was  to  get  a  product  that  was  cost-effective,  viable,  and  supportable. 
Concepts  not  supported  by  a  standard,  industry  consortium,  or  were  just  emerging  as  standards 
were  ruled  out.  Custom  design  was  added  since  that  has  been  the  option  used  in  this  industry  for 
the  past  30  years.  Table  2  shows  both  the  raw  score  and  the  weighted  score  from  the  study.  For 
more  information,  the  Development  Technology  Trade  Study  is  included  as  Appendix  F  of  this 
report. 
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7  Risk  Status  Update 


Prob 

Severity 

Interacting  with  new  advisor 

Low 

Med 

Face  to  face  meeting;  email/phone  communication 

'-^r .  i  y  V::  - ; ;  V z' 

Open 

Technically,  this  risk  is  still  open.  However  the  relationship  developed 
thus  far  into  the  project  is  working  very  well  and  is  not  expected  to  be  a 
concern.  Initially,  the  lack  of  face-to-face  meetings  was  a  concern. 

Email  and  phone  conversations  have  proven  to  be  adequate. 

1'' 

Not  meeting  user's  needs  and  requirements 

Med 

Med 

yMitigaloj" 

Interview  users,  provide  draft  documents  to  users  for 
feedback 

71"  ''i  7 

Open 

During  these  days  of  “doing  more  with  less”,  reviewing  documents  for 
other  peoples  projects  not  directly  related  to  your  own  are  low  on  the 
priority  list.  This  was  the  case  with  my  last  project  and  so  the  meager 
feedback  on  this  school  project  comes  as  no  surprise.  There  have  been 
only  a  couple  of  actual  replies  (both  positive).  Since  1  can’t  force 
people  to  read  the  document(s),  the  way  I’ve  chosen  to  get  around  this  is 
from  a  proactive  stance.  I’ve  gone  out  of  my  way  to  discuss  the  needs 
and  requirements  prior  to  writing  the  documents.  The  comments  1 
received  were  on  the  Needs  Statement. 
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Prob  Severii 


Risk 

Not  understanding  operational  environment 

Mitigator 

Use  previous  bus  monitors  (1553)  as  a  model,- talk  to 
knowledgeable  people. 

Status 

Closed 

The  Operational  Concept  Document  was  a  lot  more  in  depth  then  was 
expected.  As  a  result  of  the  detail  of  the  document,  I  think  the 
operational  environment  is  understood. 

Risk  Not  understanding  network  aspect  of  avionics _ 

Mitigator  Get  knowledgeable  people  involved  (fibre  channel  and 
_ avionics).  Do  research. _ 

Status  Open 

This  risk  was  addressed  primarily  in  the  External  Interfaces  document. 
The  only  element  remaining  on  this  project  is  the  A-Spec.  Since  the 
External  Interfaces  document  feeds  the  A-Spec  fairly  directly,  the 
probability  drops  to  low  (from  High).  Since  the  severity  is  Med,  the 


Risk 

Trade  Study:  Don’t  include  viable  option  or  don't  throw  out 
non-viable  option 

Mitigator 

Get  knowledgeable  people  involved  (fibre  channel  and 
avionics).  Do  research. 

Status 

Closed 

Identified  trade  studies  have  been  completed.  If  new  options  come  to 
light  or  new  trade  studies  need  to  be  performed,  this  risk  will  be 
reopened. 

Risk  Fall  behind  on  schedule  due  to  workload,  travel,  family 
Mitigator  Produce  realistic  schedule.  Work  to  get  ahead  when 

_ possible.  Identify  critical  path. _ 

Status  Open 

Underestimated  how  much  averaging  1 8  hours  a  week  on  top  of  work 
actually  was.  Also  underestimated  effect  of  two  major  holidays.  With 
the  end  in  sight,  believed  current  schedule  can  be  maintained.  There  is 
some  concern  with  work  related  travel  schedules  heating  up  in  Jan/Feb. 


Risk  Unknown  -  unknowns _ 

Mitigator  Perform  risk  assessment  periodically.  Keep  looking  for 
_ potential  risk  areas _ 

Status  Open 

This  element  to  remain  open  through  the  end  of  the  project. 
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1  Scope 

1.1  Identification 

This  document  applies  to  a  Fibre  Channel  Avionics  Bus  Monitor  operated  within  a  Data 
Acquisition  Network.  The  Fibre  Channel  Avionics  Bus  Monitor  is  used  to  monitor  Fibre 
Channel  avionics  busses  located  on  weapons  platforms  for  test  and  evaluation  (T&E)  purposes  - 
primarily  during  developmental  testing. 

1.2  System  Overview 

A  T&E  Data  System  is  used  to  acquire  data  during  a  test  or  mission.  This  data  is  recorded  for 
post-flight  analysis.  The  data  may  also  be  transmitted  to  a  ground  processing  facility  for  in-flight 
data  monitoring.  As  such,  the  T&E  data  system  must  be  invisible  to  the  operation  and  control  of 
the  aircraft.  The  T&E  data  system  typically  consists  of  independent  wiring,  data  acquisition 
units,  and  oftentimes  transducers.  Upon  completion  of  T&E,  the  system  is  removed  and  the 
aircraft  is  returned  to  fleet  status.  The  data  system  may  also  be  known  as  an  instrumentation 
system  or  a  telemetry  system. 

1,2.1  Background 

For  the  past  20  years,  the  avionics  bus  used  on  military  aircraft  has  been  Mil-Std-1553  (1553). 
Much  of  the  data  sent  across  the  1553  bus  is  of  interest  to  the  test  programs.  As  can  be  seen  in 
Figure  1 ,  a  bridging  system  is  used  that  gathers  the  data  of  interest  from  the  production  avionics 
system  and  formats  the  data  into  something  useful  for  the  T&E  data  system. 


Figure  1  System  Relationships 


1553  utilizes  a  ‘bus  architecture’  where  all  devices  or  remote  terminals  (RT)  are  connected  to  the 
bus  controller  (BC)  via  a  central  cable  as  shown  in  Figure  2.  Regardless  of  where  a  unit  is 
connected  to  the  bus,  all  of  the  data  on  the  bus  is  available  to  the  unit.  To  interface  to  the  1553 
bus,  the  bus  monitor  system  used  the  same  cormection  method  listed  in  Mil-Std-1553  for  the 
avionics  units.  The  bus  monitor  was  programmed  to  capture  all  of  the  data  (100%  mode)  or 
specific  data  words  (selected  data  mode). 

Bus  monitor  systems  are  usually  part  of  a  larger  T&E  data  system.  The  T&E  data  system  is 
installed  on  the  test  vehicle  to  gather  data  describing  the  state  of  the  test  vehicle  at  any  given 
moment.  The  data  system  will  gather  data  from  many  different  systems  including  both 
production  and  test  systems.  The  data  is  transmitted,  recorded  or  both. 
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Figure  2  Typical  1553  Bus  Monitor 

As  the  1  MHz  rate  of  1553  proves  to  be  inadequate  for  today’s  data  intensive  avionics  suites, 
avionics  designers  are  turning  to  high  speed,  network  based  communication  standards  like  Fibre 
Channel.  At  baud  rates  greater  than  1  GHz,  Fibre  Channel  should  be  able  to  handle  the  avionics 
data  for  years  to  come.  At  these  rates,  copper  based  wiring  plants  are  no  longer  an  option  -  fiber 
optics  must  be  used. 

1.2.2  Current  Concept 

The  basic  concept  of  tapping  into  the  avionics  bus  to  gather  data  for  the  T&E  data  system 
remains  the  same  for  Fiber  Channel  as  it  did  for  1553.  However,  with  speeds  in  excess  of  1 
Gb/s,  network  architectures,  and  fiber  optic  cabling  plants  new  paradigms  will  have  to  emerge. 
For  obvious  risk  issues,  these  new  avionics  busses  will  not  replace  the  current  1553  avionics  in  a 
single  step.  Avionics  sub-systems  will  gradually  be  converted  as  needs  and  funding  arise.  From 
the  T&E  Data  System  perspective,  both  1553  and  Fibre  Channel  Bus  Monitors  will  be  needed  for 
the  next  few  years  at  a  minimum  as  can  be  seen  in  Figure  3.  The  bus  monitor  conceptually 
consists  of  two  parts.  The  first  part  is  the  actual  interface  to  the  production  avionics  system 
identified  as  a  bus  tap.  The  second  part  is  the  unit  that  receives,  formats,  and  outputs  the  data. 

A  conceptual  block  diagram  of  the  Fibre  Channel  Bus  Monitor  unit  is  shown  in  Figure  4.  The 
Fibre  Channel  interface  receives  avionics  data  from  the  bus  tap  in  the  Fibre  Channel  Avionics 
Network.  The  avionics  message  is  time  tagged  via  a  time  circuit  that  was  synchronized  from  the 
T&E  Data  System.  The  comparator  looks  at  the  program  memory  for  avionics  messages  of 
interest.  If  the  message  in  the  buffer  was  requested,  it  passes  the  message  to  the  Output  Message 
Formatter.  The  Formatter  creates  an  output  message  based  on  whether  the  operational  mode  is 
‘Truth’  or  ‘Validate’.  Once  complete,  the  output  message  is  sent  to  the  Data  Interface  where  it 
enters  the  T&E  Data  Network.  When  in  the  Program  State,  T&E  support  unit  talks  to  the 
Program  Control  through  the  Data  Interface.  The  Program  Control  can  read,  load,  verify,  and 
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clear  the  non-volatile  program  memory.  The  Diagnostic  Control  receives  status  data  from  all 
subsystems.  When  in  the  operational  state,  a  subset  of  the  status  words  is  available  as  status 
messages  to  the  data  system.  When  in  the  diagnostic  state,  a  more  thorough  test  is  done  which 
would  interrupt  the  data  collection  during  normal  operations.  The  power  for  the  unit  is  received 
from  the  T&E  Data  System. 


Figure  3  System  Relationships 


1.2.3  System  Context 

The  primary  users  of  this  system  will  be  the  Instrumentation  Departments  at  the  major  T&E 
centers  including :  - 

•  Naval  Air  Weapons  Center  -  Aircraft  Division  (Patuxent  River) 

•  Naval  Air  Weapons  Center  -  Weapons  Division  (China  Lake) 

•  Air  Force  Flight  Test  Center  (Edwards  AFB) 

•  Air  Force  Flight  Development  Center  (Eglin  AFB) 

•  Aberdeen  Test  Center  (Army) 

These  T&E  centers  are  all  part  of  the  Range  Commanders  Council  (RCC)  and  support  the 
Telemetry  Standards  published  by  the  RCC.  These  standards  drive  the  T&E  Data  System 
interface  and  data  standards  called  out  in  this  specification.  These  standards  will  change  over 
time  as  requirements  and  capabilities  change.  There  may  also  be  other  users  desiring  this 
capability  whom  use  other  standards.  For  these  reasons,  modular  design  practices  should  be 
considered. 

Due  to  acquisition  reform,  the  Government  no  longer  desires  to  own  product  designs  but  wants 
to  buy  commercial  products.  Therefore  there  are  no  Government  support  agencies. 

1.3  Document  Overview 

The  purpose  of  this  document  is  to  provide  the  developer  with  a  product  concept  the  Government 
is  interested  in.  Towards  that  end,  this  document  will  provide  information  about  the  minimum 
requirements  for  a  Fibre  Channel  Avionics  Bus  Monitor.  Additional  capabilities,  while  always 
desired,  must  be  balanced  by  the  overall  cost  of  the  unit.  The  overall  cost  includes  the  per-unit 
purchase  cost  and  the  projected  additional  life-cycle  cost. 

Section  1  -  General  overview  and  scope  of  this  specification. 

Section  2  -  Identifies  project  documents  and  specific  issue  of  referenced  documents. 

Section  3  -  Specifies  the  requirements  for  the  Fibre  Channel  Bus  Monitor 
Section  4  -  Details  the  qualification  methods  used  to  ensure  compliance  of  the  requirements  in 
section  3. 

Section  5  -  Contains  information  pertinent  to  the  understanding  of  this  specification. 

Appendices  -  Additional  information  in  support  of  the  previous  sections. 

2  Referenced  Documents 

2.1  Project  Documents 
Document 
Statement  of  Need 
Operational  Concept  Document 
Bus  Tap  Trade  Study 
Development  Technology  Trade  Study 

2.2  Referenced  Documents 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this  document  to  the  extent 
specified  herein.  If  a  specification  is  referenced  without  indicating  any  specific  paragraphs  as 
being  applicable,  then  the  entire  specification  is  applicable.  Where  a  specific  issue  of  the 
document  is  provided  in  Section  2.2,  no  other  issue  shall  be  used  without  the  prior  'written 


Author  Date 

Sid  Jones  30-0ct-00 

Sid  Jones  30-0ct-00 

Sid  Jones  7-Jan-Ol 

Sid  Jones  7-Jan-Ol 
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approval  of  procuring  agent.  When  documents  are  referenced  herein,  a  short  form  citing  only  the 
basic  number  of  the  document  is  used.  Revision  letters,  amendment  indicators,  notices, 
supplements,  and  dates  are  omitted.  If  a  document  is  invoked  by  reference  in  Sections  3  through 
6,  but  not  listed  in  Section  2,.it  i§  applicable.  Existence  of  this  situation  should  be  called  to  the 
attention  of  the  procuring  agent.  Subsidiary  documents  shall  not  be  applied  as  requirements. 


IRIG  106-01 

Mil-Std-704A 

Mil-Std-704E 

Mil-Std-461E 

Mil-Std-810F 

ANSI  X3. 230- 1994 

ANSI  X3. 297- 1997 

ANSI  X3.303-1998 

ANSI  X3.nnn-200x" 

ANSI  X3.nnn-200x^ 

ANSI  X3.nnn-200x 

ANSI  X3.nnn-200x 
RFC-768 
RFC-2625 
SAEAS50881A 


Inter-Range  Instrumentation  Group  Telemetry  Standards,  Range 

Commanders  Council  (RCC),  2001 

Aircraft  Electric  Power  Characteristics,  09-AUG-1966 

Aircraft  Electric  Power  Characteristics,  01 -MAY- 1991 

Requirements  For  The  Control  Of  Electromagnetic  Interference 

Characteristics  Of  Subsystems  And  Equipment,  20-AUG-1999 

Environmental  Engineering  Considerations  And  Laboratory  Tests,  01- 

NOV-2000 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  (FC-PH),  1994 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  2  (FC-PH-2),  1997 

Information  Technology  -  Fibre  Channel  Physical  and  Signaling 
Interface  -  3  (FC-PH-3),  1998 

Information  Technology  -  Fibre  Channel  -  Physical  Interfaces  (FC- 
PI) 

Information  Technology  -  Fibre  Channel  -  Framing  and  Signaling 
(FC-FS) 

Information  Technology  -  Fibre  Channel  —  Virtual  Interface 
Architecture  Mapping  Protocol  (FC-VI) 

Fibre  Channel  Avionics  Environment  Profile  (FC-AEP)  (due  8/01) 
User  Datagram  Protocol  (UDP),  28-Aug-80 
IP  and  ARP  over  Fibre  Channel  (IP),  June  1 999 
Wiring,  Aerospace  Vehicle,  15-Aug-98 


3  Requirements 

3.1  Required  States  and  Modes 

The  imit  shall  have  the  following  states  as  a  minimum.  Additional  states  or  modes  are  allowed. 

3.1.1  OFF 

This  state  is  characterized  as  having  no  power  applied  to  the  power  input  interface.  There  is  no 
difference  made  to  whether  the  unit  is  sitting  on  a  storage  shelf  or  wired  in  an  operational 
configuration. 

3.1.2  OPERATIONAL 

This  is  the  normal  state  of  the  unit.  During  this  state,  data  from  the  Avionics  Bus  Monitor 
Interface  (XIF-FC)  is  formatted  based  on  internal  program  requirements  for  dissemination  across 
the  T&E  Bus  Interface  (XIF-DATA).  The  interfaces  are  shown  in  Figure  6. 


*  FC-PI  and  FC-FS  are  currently  in  work  and  will  supercede  FC-PH,  FC-PH-2,  and  FC-PH-3 
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3.1.2.1  Validate  Mode 

This  mode  is  used  when  the  quality  of  the  production  avionics  data  is  suspect.  Generally 
when  using  this  mode,  one  or  more  of  the  avionics  sub-systems  are. under  test.  The  actual 
data  values  being  sent  are  only  half  the  story.  Other  equally  important  questions  include:  the 
state  of  the  bus,  which  node  sent  the  data  and  when,  and  which  nodes  received  the  data  and 
when. 

3. 1.2.2  Truth  Mode 

This  mode  is  used  when  the  production  avionics  data  is  known  to  be  good.  The  avionics  data 
was  previously  validated  and  is  now  considered  the  truth  source  in  validating  other  systems. 
During  this  mode,  only  the  data  is  of  concern  -  not  the  state  of  the  bus. 

3.1.3  PROGRAM 

When  in  the  program  state,  the  unit  is  receiving  instructions  across  the  T&E  Bus  Interface  (XIF- 
DATA)  and  storing  them  in  non-volatile  memory  for  execution  during  the  Operational  state. 

3.1.4  DIAGNOSTIC 

The  diagnostic  state  allows  the  user  access  to  all  areas  of  memory  through  the  XIF-DATA 
interface. 

3.1.5  Requirements  Correlation 

Table  1  correlates  the  requirements  listed  in  section  3.2  with  the  states  and  modes  listed  in 
section  3.1.  The  requirements  apply  to  the  states  and  modes  as  indicated. 


Table  1  Requirements  Correlation 


f-.-r-  Staffs 

Fibre  Channel  Avionics  Bus 

Interference  with  avionics  operation 

V 

V 

Number  of  Avionics  Interfaces 

V 

V 

Number  of  Bus  Messages 

V 

V 

Number  of  Data  Words 

V 

V 

T&E  Data  System 

T&E  Data  System  Compatibility 

V 

V 

V 

Validate  Mode  Data  Format 

V 

V 

Truth  Mode  Data  Format 

v 

v 

Selected  Data 

V 

Data  Header  Format 

V 

V 

Time  Tagging 

V 

Power 

V 

V 

Programming  ports 

Software 

■/ 

3.2  System  Capability  Requirements 
3.2.1  Fibre  Channel  Avionics  Bus 
3.2.1.1  Avionics  Interface 

Individual  avionics  interfaces  (bus  tap)  at  each  node  shall  be  used.  Regardless  of  the  state  of 
the  unit  and  avionics  interface,  operation  of  the  avionics  bus  shall  not  be  compromised. 
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3.2. 1.2  Number  of  Avionics  Interfaces 

The  amount  of  data  that  can  be  monitored  is  limited  by  the  output  bandwidth  of  the  unit.  A 
single  Fibre  Channel  interface  may  consume  the  entire  output  bandwidth  available.  However, 
due  to  the  point-to-point  nature  of  Fibre  Channel  communications,  data  may  be  required  from 
multiple  nodes.  In  a  system  with  two  mission  computers  connected  to  redundant  switches,  the 
minimum  requirement  will  be  to  monitor  both  receive  lines  from  both  switches  to  each 
mission  computer  or  four  interfaces.  The  unit  shall  accommodate  1  to  n  avionics  input 
interfaces,  where  n  >  4. 

3.2.1.3  Number  of  Bus  Messages 

Fibre  Channel  avionics  systems  are  only  now  being  developed.  In  the  absence  of  hard 
numbers  for  the  quantity  of  bus  messages  available,  the  number  of  Mil-Std-1553  messages 
(2'^)  will  be  used  as  a  starting  point.  The  unit  shall  be  programmable  to  select  up  to  65536 
individual  messages. 

3.2. 1.4  Number  of  Data  Words 

Mil-Std-1553  allowed  as  many  as  32  data  words  per  message.  Theoretically,  there  is  no  limit 
on  the  number  of  data  words  allowed  in  a  given  message.  It  is  expected  that  practical  matters 
of  command  and  control  as  well  as  Fibre  Channel  frame  size  will  yield  a  data  word  per 
message  limit  of  less  than  1024.  Any  number  of  words  within  a  given  message  shall  be 
selectable  for  data  acquisition. 

3.2.2  T&E  Data  System 

3.2.2.1  T&E  Data  System  Compatibility 

The  current  DoD  data  system  standard  is  the  Common  Airborne  Instrumentation  System 
(CAIS).  To  meet  future  requirements,  the  Range  Commanders  Council  (RCC)  has  identified 
Fibre  Channel  as  the  basis  for  the  next  generation  data  system.  The  T&E  data  system 
interface  shall  be  CAIS  or  Fibre  Channel  as  defined  in  IRIG  106. 
Note:  Good  design  and  marketing  practices  would  allow  for  a  modular  interface  that  could  be  swapped  out  for 
either  interface  desired. 

3.2.2.2  Validate  Mode  Data  Format 

Validate  mode  is  used  when  the  bus  data  is  being  tested  and  therefore  not  a  source  of  truth 
data.  When  in  Validate  mode,  other  information  besides  the  data  shall  be  captured.  It  is 
expected  that  all  messages  will  be  transferred  within  a  single  Fibre  Channel  frame.  The  entire 
Fibre  Channel  frame  shall  be  time  tagged  and  encapsulated  as  the  data  payload  (less  the  start 
and  end  of  frame  identifiers)  An  example  is  shown  in  Figure  5  (A). 

3.2.2.3  Truth  Mode  Data  Format 

Truth  mode  is  used  when  the  bus  data  is  being  used  as  a  truth  source.  The  data  is  believed  to 
be  accurate.  When  in  Truth  mode,  only  the  time  tag  and  message  data  shall  be  sent  across  the 
T&E  interface.  An  example  is  shown  in  Figure  5  (B) 
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1 

! 

FC  Frame  Hdr  | 

'  MSG  ID  Bus  Msg  .  ^ 

Captured  Avionics  Fibre  Channel  Transport  Frame  (HDR  and  Data) 
Data  Header  (ID  &  Time  Tag  of  Avionics  Frame) 

(A) 


Bus  Data 

MSG  ID  Bus  Msg  :  :  ;  :  . 

Captured  Avionics  Fibre  Channel  Data 
Data  Header  (ID  &  Time  Tag  of  Avionics  Frame) 

(B) 


Figure  5  Example  Capture  Data  Format,  (A)  Validate  Mode  (B)  Truth  Mode 


3.2.2.4  Selected  Data 

Both  sections  3. 2.2.2  and  3.2.2.3  refer  to  capturing  entire  bus  messages.  When  in  Truth 
Mode,  the  option  of  capturing  specific  data  word(s)  within  a  message  shall  also  be  available. 
The  selected  data  shall  be  placed  within  1  or  more  user-defined  messages.  The  system  shall 
handle  a  minimum  of  256  user-defined  messages  of  1024  words  each. 

3.2.2. 5  Data  Header  Format 

There  is  work  underway  within  the  Range  Commanders  Council  for  definition  of  data  system 
message  formats  to  be  published  in  IRIG  1 06  at  the  time  this  specification  was  written.  When 
this  system  is  developed,  message  definitions  found  in  the  latest  version  of  IRIG  1 06  shall  be 
used.  If  IRIG  106  message  definitions  are  not  available,  the  data  header  shall  be  a  maximum 
size  consisting  of  the  following  fields;  an  8  bit  type  field,  a  16  bit  ID  field,  and  a  48  bit  time 
field  as  shown  in  Table  2.  The  system  shall  be  flexible  enough  to  create  subsets  of  the 
maximum  header,  for  example;  a  4  bit  type  field,  an  1 1  bit  ID  field  and  a  36  bit  time  field. 


Table  2  Maximum  Data  Header  (When  Not  Defined  in  IRIG  106) 


...J 

-- 

16b 

48b 

1  bits 

i  bits 

TYPE 

1 H  -  Validate  Data 

2H  -  Truth  Data 

3H  -  Selected  Data 

ID 

Uniquely  identifies  the  format  of  the  message  body 

TIME 

Time  of  first  bit  of  first  word  of  message  body 

3. 2.2.6  Time  Tagging 

Time  correlation  of  acquired  avionics  bus  data  is  accomplished  by  internal  time  counters  and 
time  tagging  circuits,  which  are  synchronized  to  the  network  time  broadcast  across  the  T&E 
data  system.  Accuracy  of  the  time  tag  shall  be  1 .0  microseconds  or  better.  The  resolution  of 
the  time  tag  shall  be  0.10  microseconds  or  better.  The  time  format  shall  be  in  accordance  with 
IRIG  106. 


8 


3.2.2. 7  Power ^ 

The  unit  shall  operate  from  Mil-Std-704E  28VDC  power  with  transient  characteristics  in 
accordance  with  figure  9  (curves  1&4)  and  figure  17  from  Mil-Std-704A. 

3. 2. 2. 8  Programming  ports 

Programmability  of  the  unit  shall  be  done  through  the  T&E  Data  System  Bus  (XIF-DATA) 
Interface.  Additional  program  ports  such  as  RS-232  and  Ethernet  are  allowed  but  shall  not 
limit  XIF-DATA  programming. 

3. 2. 2.9  Software 

Software  shall  be  provided  that  will  allow  all  modes  and  capabilities  of  the  system  to  be 
exercised.  The  software  shall  operate  on  the  following  computer  platform 

•  Microsoft  Windows  2000  Operating  System 

•  Intel  Pentium  4, 1  GHz  microprocessor 

•  128  MB  of  system  memory 

•  17  inch  monitor 

•  800  X  600  video  resolution  using  65  thousand  colors 

•  40  GB  Hard  drive 

•  Sound  Blaster  compatible  sound  card  with  speakers 

•  101  key -keyboard 

3.3  System  External  Interface  Requirements 
3.3.1  Interface  Identification  and  Diagrams 

There  are  three  external  interfaces  for  the  Fibre  Channel  Avionics  Bus  Monitor  System  -  The 
Fibre  Channel  (FC)  Avionics  Bus,  The  Test  and  Evaluation  (T&E)  Data  System  Bus,  and  T&E 
Data  System  Power.  Table  3  identifies  these  interfaces  along  with  their  associated  project 
unique  identifier  (PUID),  interfacing  entities,  and  interface  characteristics.  Characteristics 
identified  as  ‘primary’  impose  their  requirements  on  other  interfacing  entities.  Conversely, 
interfaces  identified  as  ‘secondary’  have  requirements  imposed  on  them  by  the  interfacing  entity. 
The  interfaces  are  shovm  graphically  in  Figure  6  and  will  be  discussed  in  the  succeeding 
sections. 


Table  3  External  Interfaces 


PUIB 

Interfacing  Entities 

CharactemtiK^ 

FC  Avionics  Bus  I/F 

XIF-FC 

Production  Avionics  Bus 

Secondary,  Input 

T&E  Data  System  Bus  I/F 

XIF-DATA 

COTS  Data  System  Bus 

Secondary,  Bi-directional 

XIF-PWR 

Data  System  Power  Distribution 

Secondary,  Input 

Figure  6  External  System  Interfaces 
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3.3.2  Fibre  Channel  Avionics  Bus  I/F  (XIF-FC) 

3.3.2. 1  Purpose 

This  interface  provides  avionics  data  transfer  from  the  production  avionics  bus  to  the  bus 
monitor. 

3.3.2.2  Description 

Messages  from  the  Fibre  Channel  Avionics  Bus  will  traverse  this  interface.  This  message  will 
be  encapsulated  using  transport,  network,  and  data  link  protocols  decided  upon  by  the 
avionics  designer  as  shown  in  Table  4.  The  Fibre  Channel  interface  will  have  to  adhere  to  the 
same  Fibre  Channel  standards  used  by  the  avionics  system.  At  the  top  level,  the  standards 
would  be  the  ANSI  standards  as  listed  in  section  3.3.2.10.  These  standards  are  expected  to  be 
modified  by  the  ANSI  Fibre  Channel  Avionics  Environment  Profile.  A  manufacturer  or 
platform  specific  report  may  further  modify  the  Fibre  Channel  standard  used  by  the  avionics. 
The  implication  to  this  interface  is  that  it  must  be  configurable  to  accommodate  these 
potential  differences.  Layered  on  top  of  the  Fibre  Channel  are  the  network  and  transport 
protocols.  Again,  these  may  be  different  for  various  manufacturers  and  platforms 

Table  4  XIF-FC  Layered  Model 


OSI  Layer 


Application 
Presentation 
Session 
Transport 
Network 
Data  Link 
Physical 


Standard  Standard  Body 


•v.:-  -ci::-'  -■  -i;- 


i  .i;  f  . 


"  . . .  '■  *  . .  N'-?!  I 


3.3.2.3  Priority 

The  system  shall  assign  a  high  priority  to  this  interface.  All  data  of  interest  must  be  captured. 

3.3.2.4  Type 

This  shall  be  a  real-time  interface. 

3.3.2. 5  Characteristics  of  Incoming  Data  Elements  _ 


Name 

FC  Avionics  Bus  Data 

PUID 

DI-FC 

Source 

Production  FC  Avionics  Bus 

Units 

Not  Applicable 

Data  Type 

Payload 

Range 

Not  Applicable 

Size/Format 

As  defined  in  section  0 

Accuracy 

Not  Applicable 

3. 3.2.6  Characteristics  of  Outgoing  Data  Elements 
There  shall  be  no  outbound  communication  through  XIF-FC. 
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3.3.2. 7  Characteristics  of  Communications  Methods 

The  communications  methods  that  shall  be  used  are  defined  by  the  reference  documents  in 
section  3.3.2.10  ■ 

3. 3.2.8  Characteristics  of  Protocols 

The  protocols  that  shall  be  used  are  identified  in  Table  4  and  are  defined  by  the  reference 
documents  in  section  3.3.2.10 

3. 3. 2. 9  Relationship  to  System  Modes 

The  following  table  shows  the  relationship  of  the  Fibre  Channel  Avionics  Interface  to  the 
modes  of  the  system. 

Table  5  XIF-FC  Relationship  to  System  Modes 

Mode:  OFF 

When  the  system  is  in  the  ‘OFF’  state,  i.e.  powered  down,  there  is  no  activity  on  the 
interface.  The  interface  method  shall  not  interfere  with  normal  avionics  operation 
when  the  bus  monitor  is  powered  off. 

Mode:  OPERATIONAL 

During  OPERATIONAL  mode,  the  interface  is  active.  Data  appearing  on  the 
avionics  bus  is  sent  across  the  interface  where  the  system  decides  to  send  it  forward 
or  throw  it  away. 

Mode:  PROGRAM 

During  PROGRAM  mode,  the  interface  is  not  active.  The  interface  method  shall  not 
interfere  with  normal  avionics  operation  when  the  bus  monitor  is  in  PROGRAM 
mode. 

Mode:  DIAGNOSTIC 

During  DIAGNOSTIC  mode,  the  interface  is  not  active.  The  interface  method  shall 
not  interfere  with  normal  avionics  operation  when  the  bus  monitor  is  in 
DIAGNOSTIC  mode. 


3.3.2.10  XIF-FC  Reference  Documents 
FC-PH  FC-PI 

FC-PH-2  FC-FS 

FC-PH-3  FC-VI 

FC-AEP 

For  specific  issue  information,  see  section  2.2 


3.3.3  T&E  Data  System  Bus  (XIF-DATA) 

3.3.3. 1  Purpose 

This  interface  outputs  formatted  avionics  bus  messages  transferred  from  the  bus  monitor 
system  to  the  T&E  Data  System  as  well  as  receives  system  programming  information. 

3.3. 3.2  Description 

In  the  near  future,  the  T&E  Data  System  Bus  is  expected  to  migrate  to  a  Fibre  Channel  based 
system  as  defined  in  the  ANSI  Fibre  Channel  Standards  and  modified  by  the  IRJG  (Interrange 
Instrumentation  Group)  Telemetry  Standards  Part  II  as  shown  in  Table  6.  The  interface  will 
reside  in  the  bus  monitor  and  be  perceived  by  the  data  system  as  another  node. 
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Table  6  XIF-DATA  Layered  Model 
OSI  Layer  Standard  Standard  Body 


3.3.3J  Priority 

The  system  shall  assign  a  medium  priority  to  this  interface. 
3.3.3.4  Type 

This  shall  be  a  real-time  interface. 


3. 3. 3. 5  Characteristics  of  Incoming  Data  Elements 


Name 

System  Programming  Data 

PUID 

DI-SPD 

Source 

T&E  Data  System  Support  Unit 

Units 

Not  Applicable 

Data  Type 

Payload 

Range 

Not  Applicable 

Size/Format 

TBD 

Accuracy 

Not  Applicable 

3.3,3, 6  ' 

Characteristics  of  Outgoing  Data  Elements 

Name 

T&E  Formatted  Avionics  Data 

PUID 

DO-FAD 

Source 

Internal 

Units 

Not  Applicable 

Data  Type 

Payload 

Range 

Not  Applicable 

Size/Format 

As  defined  in  section  3.3.3.10 

Accuracy 

Not  Applicable 

3.3.3. 7  Characteristics  of  Communications  Methods 

The  communications  methods  that  shall  be  used  are  defined  by  the  reference  documents  in 
section  3.3.3.10 

3.3.3.8  Characteristics  of  Protocols 

The  protocols  that  shall  be  used  are  identified  in  Table  6  and  are  defined  by  the  reference 
documents  in  section  3.3.3.10 

3.3.3. 9  Relationship  to  System  Modes 

The  following  table  shows  the  relationship  of  the  T&E  Data  System  Interface  to  the  modes  of 
the  system. 
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Table  7  XIF-DATA  Relationship  to  System  Modes 


Mode:  OFF 

When  the  system  is  in  the  ‘OFF’  state,  i.e.  powered  down,  there  is  no  activity  on  the 
interface. 

Mode:  OPERATIONAL 

During  OPERATIONAL  mode,  the  interface  is  active.  Avionics  data  is  formatted 
and  given  a  destination  address  within  the  T&E  data  system.  The  data  flow  across 
the  interface  is  primarily  from  the  bus  to  the  T&E  system  in  the  form  of  avionics 
data.  There  may  be  some  command  activity  being  received  by  the  interface  from  the 
T&E  system. 

Mode;  PROGRAM 

During  PROGRAM  mode,  the  interface  is  receiving  data  from  the  T&E  system  and 
stores  the  data  in  non-volatile  program  memory.  Data  being  transmitted  across  the 
interface  will  be  limited  to  program  acknowledgement  type  of  data. 

Mode:  DIAGNOSTIC 

During  DIAGNOSTIC  mode,  the  interface  is  transmitting  internal  diagnostic  data 
from  throughout  the  bus  monitor  to  the  T&E  Data  System.  There  may  be  some 
_ command  activity  being  received  by  the  interface  from  the  T&E  system _ 


3.3,3.10  XIF-DATA  Reference  Documents 


IRIG  106 

FC-PI 

FC-PH 

FC-FS 

FC-PH-2 

IP 

FC-PH-3 

UDP 

FC-AEP 

For  specific  issue  information,  see  section  2.2 

3.3.4  T&E  Data  System  Power  (XIF-PWR) 

3.3.4. 1  Purpose 

This  interface  provides  the  power  needed  to  run  the  Fibre  Channel  Avionics  Bus  Monitor. 

3. 3. 4. 2  Description 

The  T&E  Data  System  will  provide  the  power  required  to  run  the  Fibre  Channel  Avionics  Bus 
Monitor.  The  T&E  data  system  shall  distribute  raw  aircraft  power  or  regulated  power.  This 
allows  a  master  switch  to  shut  down  the  entire  data  system. 

3. 3.4.3  Priority 

The  system  shall  assign  a  moderate  priority  to  this  interface. 

3. 3.4.4  Type 

This  is  a  non-data  interface. 


3.3.4.5  Characteristics  of  Incoming  Elements 


Name 

T&E  Data  System  Power 

PUID 

DI-PWR 

Source 

Production  FC  Avionics  Bus 

Units 

Volts 

Data  Type 

Power 

Range 

22.0  to  29.0  steady  state 

Size/Format 

Not  Applicable 

Ripple 

1 .5  max 

Governing 

Standard 

28Volts  as  defined  in  Mil-Std-704E 

Transient 

Transient  response  as  defined  in  Mil-Std- 
704 A  (fig  9  curves  1&4  and  fig  17) 
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3.3.4.6  Characteristics  of  Outgoing  Elements 

There  shall  be  no  outbound  elements  through  XIF-PWR. 

3.3.4. 7  Characteristics  of  Communications  Methods 
Not  Applicable 

3. 3. 4. 8  Ch  aracteristics  of  Protocols 
Not  Applicable 

3. 3. 4. 9  Relationship  to  System  Modes 

Table  8  shows  the  relationship  of  the  T&E  Data  System  Power  Interface  to  the  modes  of  the 
system. 

Table  8  XIF-PWR  Relationship  to  System  Modes 

Mode:  OFF 

When  the  system  is  in  the  ‘OFF’  state,  i.e.  powered  down,  there  is  no  activity  on  the 
interface. 

Mode:  OPERATIONAL 

During  OPERATIONAL  mode,  the  interface  is  active.  28  VDC  is  supplied  to  the 
Bus  Monitor. 

Mode:  PROGRAM 

During  PROGRAM  mode,  the  interface  is  active.  28  VDC  is  supplied  to  the  Bus 
Monitor. 

Mode:  DIAGNOSTIC 

During  DIAGNOSTIC  mode,  the  interface  is  active.  28  VDC  is  supplied  to  the  Bus 
Monitor. _ _ _ _ _ 


3.3.4.10  Reference  Documents 

Mil-Std-704A*  Mil-Std-704E 

*  This  document  is  no  longer  available.  Transient  characteristics  are 
supplied  in  the  appendix  for  completeness. 

For  specific  issue  information,  see  section  2.2 

3.3.5  Summary  of  Data  Elements 


Table  9  Summary  of  Data  Elements 


XIF-FC 

DI-FC 

Fibre  Channel  Avionics  Bus  Data 

XIF-DATA 

T&E  Data  Systems  Bus 

DI-SPD 

System  Programming  Data 

DO-FAD  1 

T&E  Formatted  Avionics  Data 

XIF-PWR 

T&E  Data  System  Power 

Dl-PWR 

Bus  Monitor  Power 

XI F  -  External  Interface 

D  -  Data  Element;  I  -  input;  Output  \ 

3.4  System  Internal  Interface  Requirements 

There  are  no  internal  interface  requirements  identified  for  this  system. 

3.5  System  Internal  Data  Requirements 

There  are  no  internal  data  requirements  identified  for  this  system. 
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3.6  Adaptation  Requirements 

3.6.1  Avionics  Compatibility 

The  Fibre  Channel  standard  does  not  guarantee  interoperability.  Given  the  absence  of  a  Fibre 
Channel  Avionics  standard,  it  is  envisioned  that  manufacturers  of  different  platforms  may  design 
their  Fibre  Channel  avionics  network  differently.  This  unit  shall  be  configurable  to 
accommodate  multiple  Fibre  Channel  avionics  approaches.  Configurability  may  include 
software  programmability,  personality  module  replacement,  or  other  design  approach  that  allows 
the  user  to  reconfigure  the  unit  for  a  specific  application.  Configuring  the  system  between  Fibre 
Channel  avionics  systems  that  are  in  operation  at  time  of  award  shall  not  require  more  than  25% 
additional  cost. 

3.7  Safety  Requirements 

3.7.1  Explosive  Atmosphere 

The  equipment  shall  not  cause  ignition  of  an  ambient-explosive-gaseous  mixture  with  air  when 
operating  in  such  an  atmosphere. 

3.8  Security  and  Privacy  Requirements 

There  are  no  security  and  privacy  requirements  for  the  system.  Security  requirements  are  levied 
against  the  storage  and  telemetry  systems. 

3.9  System  Environment  Requirements 

Unless  otherwise  specified,  the  bus  monitor  shall  conform  to  the  requirements  when  subjected  to 
the  environmental  conditions  listed  below. 

3.9.1  Storage  Temperature 
-55°Cto+100°C 

3.9.2  Operating  Temperature 

The  thermal  design  shall  take  into  consideration  ambient  air  using  convection  and  radiation  only. 
Forced  air  and  heat  sinking  shall  not  be  required. 

-40°C  to  +85°C 

3.9.3  Pressure  Altitude 

-1000  feet  to  +85,000  feet 

3.9.4  Temperature/Altitude 

Combined  conditions  of  +85 °C  and  85,000  feet 

3.9.5  Relative  Humidity 

99  percent,  condensing 

3.9.6  Vibration 

■  5  to  14  Hz  at  0.20  inch  double  amplitude 

■  1 4  to  20  Hz  at  0. 1 0  inch  double  amplitude 

■  20  to  33  Hz  at  2g  acceleration 

■  33  to  74  Hz  at  0.036  inch  double  amplitude 

■  74  to  2000  Hz  at  lOg  acceleration 

3.9.7  Shock 

3.9.7. 1  Crash  Worthiness 
Peak  Acceleration;  40g,  each  axis 
Method  516.4,  procedure  5 
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3.9. 7. 2  Operational 

Peak  acceleration:  20g 
Duration:  6  to  9’  rnilliseconds 
Axis:  all  axes  ,, 

Method  5 1 6.4,  procedure  1 . 

3.9.8  Electromagnetic  Compatibility  Limits 

Conducted  Emission  (CEOS),  Radiated  Emissions  (RE02)  and  Radiated  Susceptibility  (RS03) 
perMIL-STD-461C. 

3.9.9  Sand  and  Dust 

The  equipment  shall  withstand,  in  both  operating  and  non-operating  condition,  exposure  to  sand 
and  dust  particles  as  outlined  in  MIL-STD-810E. 

3.9.10  Fungus 

The  equipment  shall  withstand,  in  both  operating  and  non-operating  condition,  exposure  to 
fungus  growth  as  encountered  in  tropical  climates.  In  no  case  shall  overall  spraying  of  the 
equipment  be  necessary.  If  it  can  be  shown  non-nutrient  materials  are  used,  fungus  test  may  be 
accomplished  by  analysis. 

3.9.11  Salt  Atmosphere 

The  equipment  shall  withstand,  in  both  operating  and  non-operating  condition,  exposure  to  salt- 
sea  atmosphere. 

3.10  Computer  Resource  Requirements 

There  are  no  additional  computer  resource  requirements  that  have  not  already  been  identified 
elsewhere  in  this  document. 

3.11  System  Quality  Factors 

3.11.1  Reliability 

Reliability  shall  be  measured  in  Mean  Time  Between  Failures  (MTBF).  The  Fibre  Channel 
Avionics  Bus  Monitor  system  shall  have  an  MTBF  greater  than  1 000  hours. 

3.11.2  Maintainability 

Maintainability  shall  be  measured  in  Mean  Time  To  Repair  (MTTR).  The  Fibre  Channel 
Avionics  Bus  Monitor  system  shall  have  an  MTTR  less  than  30  minutes.  Repair  shall  be  limited 
to  identification  and  replacement  of  the  appropriate  shop  replaceable  assembly  (SRA). 

3.12  Design  and  Construction  Constraints 

3.12.1  Size 

Due  to  small  spaces  available  in  tactical  aircraft  for  instrumentation,  the  bus  monitor  shall  be  no 
larger  than  256  in^  exclusive  of  mounting  tabs  and  mating  connectors. 

3.12.2  Weight 

Given  the  size  requirements  in  3.12.1,  weight  is  not  an  issue. 

3.12.3  Mounting 

Due  to  small  spaces  available  in  taetical  aircraft  for  instrumentation,  the  bus  monitor  shall  have 
all  connectors  located  on  one  face. 

3.12.4  Connectors 

The  connectors  used  by  the  bus  monitor  shall  be  EMI  shielded  and  have  a  positive  lock 
mechanism.  Connector  choice  and  input/output  design  shall  adhere  to  SAE  AS50881. 
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3.12.5  Color 

The  color  of  the  bus  monitor  shall  be  orange  to  identify  it  as  test  equipment. 

3.13  Personnel  Related  Requirements 

3.13.1  Connectors 

The  spacing  of  the  connectors  shall  be  adequate  for  mating  and  unmating  as  defined  in  SAE 
AS50881. 

3.13.2  Power 

The  power  supply  shall  be  reverse  polarity  protected. 

3.14  Training  Related  Requirements 

3.14.1  Help  Screens 

Training  requirements  on  the  system  shall  be  limited  to  context  sensitive  help  screens  on  the 
software  user’s  interface.  The  help  screens  shall  be  sufficiently  detailed  that  a  high  school 
graduate  that  has  prior  experience  with  bus  monitor  systems  can  operate  the  system. 

3.15  Logistics  Related  Requirements 

As  this  is  a  commercial  product,  there  are  no  logistics  related  requirements. 

3.16  Other  Requirements 

3.16.1  Technical  Manuals 

The  technical  manual  shall  be  organized  from  a  functional  perspective.  A  section  allocating  the 
functions  to  the  physical  hardware  or  software  shall  also  be  provided.  The  technical  manuals 
shall  be  written  to  a  high  school  graduate  level. 

3.17  Packaging  Requirements 

The  system  shall  be  packaged  to  withstand  shipping  by  commercial  carriers. 

3.18  Precedence  and  Criticality  of  Requirements 

This  system  shall  be  approached  from  a  life  cycle  cost  perspective.  The  trade-offs  between 
initial  cost,  performance,  and  reliability  shall  be  made  based  on  a  10-year  life  span.  It  is 
expected  by  that  time,  avionics  capabilities  will  have  changed  sufficiently  to  require  major 
upgrades  or  redesigns  of  the  bus  monitor  system. 


The  requirement  in  section  3. 2. 1.1,  Avionics  Interface  concerning  not  compromising  normal 
avionics  operations  is  consid-^red  a  critical  requirement.  The  test  plan  for  this  item  shall  be 
approved  by  the  Government. 


4  Qualification  Provisions 


The  following  qualification  methods  shall  be  used  to  ensure  the  requirements  have  been  met  as 
listed  in  Table  10. 


•  Demonstration 


•  Test 

•  Analysis 

•  Inspection 


The  operation  of  the  system,  or  a  part  of  the  system  that  relies  on  observable 
functional  operation  not  requiring  the  use  of  instrumentation,  special  test  equipment, 
or  subsequent  analysis. 

The  operation  of  the  system,  or  a  part  of  the  system,  using  instrumentation  or  other 
special  test  equipment  to  collect  data  for  later  analysis. 

The  processing  of  accumulated  data  obtained  from  other  qualification  methods. 

The  visual  examination  of  system  components,  documentation,  etc. 
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Table  10 


3.1  Required  States  and  Modes 


3.1.1  OFF _ 

3.1.2  OPERATIONAL _ 

_ 3. 1.2.1  Validate  Mode _ 

_ 3. 1.2. 2  Truth  Mode _ 

3.1.3  PROGRAM _ 

3.1.4  DIAGNOSTIC _ 

3.1.5  Requirements  Correlation _ 

3.2,  System  Capability  Requirements _ 

3.2.1  Fibre  Channel  Avionics  Bus _ 

_ 3 .2. 1 . 1  Avionics  Interface _ 

3.2. 1 .2  Number  of  Avionics  Interfaces 

_ 3.2.1 .3  Number  of  Bus  Messages _ 

_ 3.2. 1.4  Number  of  Data  Words _ 

3.2.2  T&E  Data  System _ 

_ 3 .2.2.1  T&E  Data  System  Compatibility 

_ 3.2.2.2  Validate  Mode  Data  Format _ 

_ 3.2.2.3  Truth  Mode  Data  Format _ 

_ 3.2.2.4  Selected  Data _ 

_ 3 .2.2.5  Data  Header  Format _ 

_ 3.2.2.6  Time  Tagging _ 

_ 3.2.2.7  Power _ 

_ 3.2.2. 8  Programming  ports _ 

_ 3.2.2.9  Software _ 

3.3  System  External  Interface  Requirements 

3.3.1  Interface  Identification  and  Diagrams 

3.3.2  Fibre  Channel  Avionics  Bus  I/F  (XIF-FC' 

3.3.3  T&E  Data  System  Bus  (XIF-DATA) 

3.3.4  T&E  Data  System  Power  (XIF-PWR) 

3.3.5  Summary  of  Data  Elements _ 

3.4  System  Internal  Interface  Requirements 

3.5  System  Internal  Data  Requirements _ 

3.6  Adaptation  Requirements _ 

3.6.1  Avionics  Compatibility _ 

3.7  Safety  Requirements _ 

3.7.1  Explosive  Atmosphere _ 

3.8  Security  and  Privacy  Requirements 
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5  Notes 

5.1  Terms,  Acronyms  and  Abbreviations 

1553  Mil-Std-1553 

ANSI  American  National  Standards  Institute 

avionics  science  and  technology  of  electronic  systems  and  devices  for  aeronautics 

and  astronautics 
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DI-FC 

DI-PWR 

DI-SPD 

DO-FAD 

DoD 

CAIS 

.COTS 

EMI 

FC 

FC-AEP 

FC-FS 

FC-PH 

FC-PH-2 

FC-PH-3 

FC-PI 

FC-VI 

Fibre  Channel 


BC  1 553  Bus  Controller;  directs  data  transfers  on  the  1 553  bus 

data  system  One  of  several  terms  that  refer  to  an  independent  system  installed  for 

collecting,  transmitting,  and  recording  test  data 
Project  unique  identifier  -  Fibre  Channel  avionics  system  data  element 
Project  unique  identifier  -  Power  data  element 
Project  unique  identifier  -  System  programming  data  element 
Project  unique  identifier  -  Formatted  avionics  data  element 
Department  of  Defense 

Common  Airborne  Instrumentation  System;  The  current  DoD  standard 
instrumentation  bus 
Commercial  Off  The  Shelf 
Electromagnetic  interference 
Fibre  Channel 

Document;  Fibre  Channel  Avionics  Environment  Profile 
Document;  Fibre  Channel  Framing  and  Signaling 
Document;  Fibre  Channel  Physical  and  Signaling 
Document;  Fibre  Channel  Physical  and  Signaling  2 
Document;  Fibre  Channel  Physical  and  Signaling  3 
Document;  Fibre  Channel  Physical  Interfaces 
Document;  Fibre  Channel  Virtual  Interface  Architecture  Mapping 
An  ANSI  standard  that  provides  a  general  transport  vehicle  for  Upper 
Level  Protocols  (ULPs)  such  as  Intelligent  Peripheral  Interface  (IPI)  and 
Small  Computer  System  Inter-face  (SCSI)  command  sets,  the  High- 
Performance  Parallel  Interface  (HIPPI)  data  framing,  IP  (Internet 
Protocol),  IEEE  802.2,  and  others. 

IP  Internet  Protocol 

instrumentation  system  One  of  several  terms  that  refer  to  an  independent  system  installed  for 
collecting,  transmitting,  and  recording  test  data 

IRIG  InterRange  Instrumentation  Group;  this  group  is  now  known  as  the  Range 

Commanders  Council  (RCC).  The  term  is  still  found  on  documents 
produced  by  the  RCC. 

A  common  avionics  bus  used  by  the  military 
Mean  Time  Between  Failures 

A  narrowing  in  scope  of  a  broad  standard  to  aid  interoperability  for  a 
particular  puipose 
Project  Unique  Identifier 
Range  Commanders  Council  (aka  IRIG) 

Remote  Terminal  on  a  1553  bus.  The  RT  is  directed  by  the  BC. 

Test  &  Evaluation 

One  of  several  terms  that  refer  to  an  independent  system  installed  for 
collecting,  transmitting,  and  recording  test  data 
User  Datagram  Protocol;  a  transport  layer  protocol 
Project  unique  identifier  -  T&E  data  system  external  interface 
Project  unique  identifier  -  Fibre  Channel  avionics  system  external 
interface 

XIF-PWR  Project  unique  identifier  -  Power  external  interface 


Mil-Std-1553 

MTBF 

profile 

PUID 

RCC 

RT 

T&E 

telemetry  system 
UDP 

XIF-DATA 

XIF-FC 
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Appendix  A:  Mil-Std-704A  Transient  Characteristics 

iai/-STI>-70/*A 
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nOURE  9.  Transient  sm-ge  dc  voltagS  stdp  fttftctien  dofcl  llMts 
for  category  B  equipment 
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FIGURE  17*  Emrelope  of  splJce  roK^^QB  for  dc  equipment 
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assumed  a  custom  design  would  utilize  a  32  bit  PCI  bus  or  equivalent 
d  common  miniature  data  acquisition  card  size  of  2.5x2.5. 
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